Announcement Announcement Module
Collapse
No announcement yet.
MDB-like functionality Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • MDB-like functionality

    Any word on when the framework will support MDB-like functionality? I have a servlet application that needs to use JMS but I don't want to deal with using EjBS (also, it may need to run on Tomcat). I've been using commons-messenger for pub/sub, though I recently switched to Spring for pub and was wondering when sub functionality would be available.

    Thanks,

    Drew

  • #2
    Interested as well. Maybe just a timeframe?

    I'd like to mimic mdb's as much as possible, as consumers. One to swap my message handling in and out of app servers, and two, because it's so simple, from the developer standpoint, at least...

    --pete

    Comment


    • #3
      The previous sandbox code had more sub functionality if you need it now and don't have time to develop it yourself. In general Spring JndiObjectFactoryBean made JMS easy enough the rest is just wrappers and callbacks. I do believe the new JMS stuff is taking a better long term approach.

      Comment


      • #4
        FWIW I'll be hopefully hacking together a simple alternative to MDB soon which will be using Spring.

        My current thoughts are I'll probably try reuse the JCA code in Geronimo and just add a nice simple dependency-injection based POJO API on top if thats easy to do (just so we reuse the XA and JCA processing code). But if thats too hard I might just write a simple replacement of that code.

        I"ll ping this forum when there's anything to look at

        Comment


        • #5
          sounds great! can't wait to test it out.

          Wasn't there a plan to add JCA to spring? I only mention it to try to save you some work...

          --pete

          Comment


          • #6
            Thanks Pete.

            Yes I think there was discussion of adding JCA support in a similar way to JTA / JMS / JDBC.

            The JCA support I meantioned above is for server side JCA - i.e. maintaining JCA pools of Managed Connections and Resource Adapters and handling the pools of beans, threads, transactions and so forth - rather than being JCA client side (using a JCA connection to send a JMS message for example).

            But yes, the aim is to reuse as much code as possible

            Comment


            • #7
              If I may ask why?

              Originally posted by jstrachan
              FWIW I'll be hopefully hacking together a simple alternative to MDB soon which will be using Spring.

              My current thoughts are I'll probably try reuse the JCA code in Geronimo and just add a nice simple dependency-injection based POJO API on top if thats easy to do (just so we reuse the XA and JCA processing code). But if thats too hard I might just write a simple replacement of that code.

              I"ll ping this forum when there's anything to look at
              Question for James on this:
              I was able to incorporate the code in Activemq's source distribution (org.codehaus.activemq.tool.ConsumerTool) as a bean in a Spring application hosted in Tomcat and get a similar behavior as an MDB. I still have to start the Broker separately, but I'm planning to automate that too (when Tomcat is started).

              So why won't this solution be sufficient?
              Why do we need JCA code from Geronimo?

              BTW, I'm asking for education, not as a challenge

              Comment


              • #8
                Re: If I may ask why?

                Originally posted by wgunadi
                Originally posted by jstrachan
                FWIW I'll be hopefully hacking together a simple alternative to MDB soon which will be using Spring.

                My current thoughts are I'll probably try reuse the JCA code in Geronimo and just add a nice simple dependency-injection based POJO API on top if thats easy to do (just so we reuse the XA and JCA processing code). But if thats too hard I might just write a simple replacement of that code.

                I"ll ping this forum when there's anything to look at
                Question for James on this:
                I was able to incorporate the code in Activemq's source distribution (org.codehaus.activemq.tool.ConsumerTool) as a bean in a Spring application hosted in Tomcat and get a similar behavior as an MDB. I still have to start the Broker separately, but I'm planning to automate that too (when Tomcat is started).

                So why won't this solution be sufficient?
                Why do we need JCA code from Geronimo?

                BTW, I'm asking for education, not as a challenge
                Your solution is totally sufficient for the simple case - creating a single consumer for a destination and registering a MessageListener.

                Where it breaks down is handling more complex issues like

                * pooling of MessageListener instances so that multiple messages can be processed in parallel (e.g. if you want to process messages on a queue, you might wanna process them in parallel, using 1 MessageListener per thread or something)

                * automatic handling of transactions & security and all the other J2EE things - e.g. using MDBs you can let the MDB container automatically take care of JMS or XA transactions for you

                For the simple case where transactions are not required, you can just create N consumers for a given queue and you've a reasonable solution using pure JMS. Ultimately though, I wanted a simple POJO & dependency injection based alternative to MDBs which supported both consuming & sending of messages.

                So really its just a matter of implementing a little container for managing the MDBs and dispatching the messages - which is really what the JCA container does in J2EE anyways - so I was wondering about just reusing that code, but putting a simple Spring dependency injection facade on top so its very simple & easy to use for a developer - particularly one used to Spring - and we solve the problem without having to write too much duplicate code.

                Comment


                • #9
                  FWIW I'll be hopefully hacking together a simple alternative to MDB soon which will be using Spring.
                  Is there some sample code available for this?

                  Thanks,
                  Sanjiv

                  Comment


                  • #10
                    Originally posted by sjivan
                    FWIW I'll be hopefully hacking together a simple alternative to MDB soon which will be using Spring.
                    Is there some sample code available for this?

                    Thanks,
                    Sanjiv
                    Yes - see the example code described on this page...

                    http://activemq.codehaus.org/JCA+Container

                    Comment


                    • #11
                      I just downloaded the ActiveMQ 1.5 distribution. I see another sample in the distribution under modules/spring/src/test/org/codehaus/activemq/spring.

                      Seems like the difference between the two is that the sample you pointed me to uses a JCA adapter while this version is the simple non JCA version.

                      Comparing the simple solution to the JCA solution, you said :

                      * pooling of MessageListener instances so that multiple messages can be processed in parallel (e.g. if you want to process messages on a queue, you might wanna process them in parallel, using 1 MessageListener per thread or something)
                      What if my consumer message listener in the simple version is stateless and does not require any synchronization? Like receive message and insert message data in a database. Multiple messages should be processed in parallel. Please correct me if I'm missing something.

                      The simpler version is ,well, simpler compared to the JCA version and I would prefer to use it if it meets my needs.

                      Thanks,
                      Sanjiv

                      Comment


                      • #12
                        BTW humblest apologies, the 1.5 release didn't include the latest greatest JCA stuff, we'll be doing a new release fairly soon...

                        The nice thing about the JCA version is it handles pooling of connections & sessions; whether you use a single stateless MessageListener or not.

                        If you want to avoid JCA, you could write some Java code to create N connection, sessions and consumers and register your MessageListener that way; but its a fair amount of work & would be a fixed size; with JCA you can let the pool size grow & shrink with load.

                        Note if you create multiple consumers on the same sesssion via the JMS API, messages are only dispatched one at a time.

                        In terms of resources (threads, sockets, RAM etc) the most efficient way of consuming messages in parallel is via JCA as it does some clever things under the covers (e.g. using ServerSessionPool) as well as handling acknowledgement, JMS transactions and XA. Though by all means go for the simple route if you prefer; before the JCA container came along I often did the same on projects

                        Comment

                        Working...
                        X