Announcement Announcement Module
Collapse
No announcement yet.
Spring and container features for JMS on the Tomcat 5 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring and container features for JMS on the Tomcat 5

    Spring users and authors,

    I would like to describe the JMS related problem to you all, and then ask you for a suggestion if and how can Spring help us with the solution.

    Description of the problem:


    We plan to use JMS (1.0.1) compliant MQ product between two applications running Tomcat 5 as a web app. container. Both applications are clustered with at least 2 boxes.

    We would like to have publish-subscribe, asynchronous transaction going
    between two apps. App A issues a messages requesting some info from the application B. App B is subscribed and it asynchronously picks up messages, processes them and responds to the reply queue (topic.) App B is subscribed to the reply queue (topic), and handles the responses.


    Pretty straightforward, typical asynch. queue based integration.



    I could do this easily in JBoss utilizing the Message beans. Clustering, tx demarcation and pooling would be handled by the EJB container, and JMS.

    My question is:

    Can I get the similar JMS related services on the Tomcat, but instead of utilizing the JBoss' EJB cluster enabled container services use Spring's container services. If yes - please tell me what, and if possible give me some direction on how?


    Thanks advance,
    Edmon Begoli

    P.S.

    Tomcat 5 is the key word in this architecture, because Tomcat 5 fits our bill 100% in every other aspect of our application, and we would really like to continue using it even for this solution if anyhow possible.

  • #2
    Using JMS in Tomcat

    Absolutely, you can use JMS perfectly well inside Tomcat without needing EJB containers, XA or Message Driven Beans.

    We hope soon to have a nice lightweight Spring container alternative to MDBs but until then you can still implement what you're trying to do using JMS pretty easily.

    BTW I'd recommend you try a JMS 1.1 provider as the API is now much more polymorphic & simpler that in 1.0.2b.

    The JMS provider will handle the clustering, load balancing and failover for you - so there's no need for any other technology other than Tomcat + a decent JMS provider.

    For a nice & simple easy deployment architecture you could use ActiveMQ using embedded brokers and discovery, so that there are no separate newtork services - each Tomcat basically has its own JMS message broker - and the Tomcat's will all auto-discover each other.


    From a code perspective, all you need to do is to create a Connection in each WAR deployment and create one or more MessageConsumer and MessageProducers to handle the sending and receiving of messages.

    For each consumer in A I'd create a TemporaryQueue and subscribe to it (to listen to the responses). Then send the requests on a queue for B, setting the temporary queue on the JMSReplyToDestination on the message. Then the MessageConsumer in B can process the message and send a reply back to the correct consumer. The QueueRequestor in JMS might make it easier for you to use.

    At some point I'd like to create a JMS remoting layer for Spring to make this all much simpler and invisible; however until then its still totally possible to do what you need using just Tomcat and a JMS provider like ActiveMQ - you've just a little bit of JMS plumbing code to write for now, until Spring automates this for you.

    Comment


    • #3
      James,

      Thank you for trying to answer my question.

      I understand that you can use JMS on the tomcat, and spring, but my question is really related to the pooling and load balancing of the plain Java MessageListeners (pub-sub scenario) in the clustered WebContainer.

      Let say that I have class MySubscriber subscribed to a topic MyTopic. (I am really refering to publish-subscribe scenario)
      If my application is running in a cluster of lets say two, I will have two identical instances of MySubscriber listening
      to MyTopic.

      What happens when message arrives to a topic?

      If my listener is a MessageBean deployed in an EJB container, container would manage the processing of the message - it would hand off the message to one of the instances of MySubscriber.

      In the case that MySubscriber is a plain java implementation of
      Code:
      java.jmx.MessageListener
      deployed in a clustered Web Application, both instances of MySubscriber would pick up the message, and process it - hence double work, or transactional conflict. A big deal for my "10,000 requests a day" application.

      Am I correct so far? If I am not please educate me on how would
      non-EJB container handle the pooling and load balancing of the MessageListeners in a clustered (multi-JVM) environement.

      In the cluster, Web container such as Tomcat does not pool or manage requests for any other Java objects, but servlets, http sessions, contexts and configs.
      Web container will not be aware that there are two identical listeners,
      and it would not be able to load balance these.


      My Spring related question is: Is there anything in the Spring IoC container that would provide pooling and load balancing services to the plain java MessageListeners when running in a cluster (multi-JVM, multi-machine logical and physical cluster)?

      I have my own idea how could we utilize web container services to bring pool, and instance management to Spring, but my question is - does Spring already have it?

      Regards,
      Edmon Begoli

      Comment


      • #4
        OK first things first. If you have 2 Topic subscribers running in 2 different servers (whether its straight JMS or MDBs deployed in 2 separate EARs/servers) then each message published to the topic will be delivered twice. i.e. every WAR / EAR deployment will each get a copy of the message. If you want to avoid this and only process things once, use a Queue.

        A Queue guarrentees that each message will only be processed by one single MessageConsumer; with Topics every MessageConsumer with a suitable subscription will get a copy.

        So if you are processing units of work, Queues are the way to go. Note all of the above applies to just regular JMS programming as well as EJB / MDBs too.


        If you're using MDBs, then the MDB container often uses a single MessageConsumer but then rather than processing the messages synchronously as they arrive, they are processed in the thread pool concurrently. This allows, say, 10 messages to be processed concurrently - but for each MessageConsumer each message is only processed once.

        Its pretty easy to replicate this feature by creating a single JMS MessageConsumer and then using the util.concurrent library to process the message asynchronously in a thread pool such as the Executor class (remembering to call Message.acknowledge() when processing is complete).

        So to answer your final question; the JMS provider will provide the load balancing for you if you are using queues. The only thing you need to do then is create a number of Sessions & MessageConsumers on the queue so that you can process messages concurrently. Whether you create 1 consumer and process the messages in a thread pool, or just create multiple sessions & consumers doesn't really make that much difference - the former is probably easier.

        Hopefully soon we'll have some JMS pooling code in Spring which could automate the pooling of sessions/consumers to kind of replicate the kinds of features MDBs give you but without needing a full EJB container.

        Comment


        • #5
          You can use Mule (http://www.muleumo.org) with spring to provide jms session/consumer pooling. Mule integrates fully with Spring and has a set of message providers including jms that allow spring beans to send and receive messages in a SOA. It supports jms 1.1 and 1.0.2. Clustering right now can be handled by the jms server, but there are plans provide Mule clustering.

          Comment


          • #6
            Thanks

            Thanks to both of you guys. You helped me move in the right direction.

            Regards,
            Edmon Begoli

            Comment


            • #7
              Originally posted by ebegoli
              James,

              Thank you for trying to answer my question.

              I understand that you can use JMS on the tomcat, and spring, but my question is really related to the pooling and load balancing of the plain Java MessageListeners (pub-sub scenario) in the clustered WebContainer.

              [snip]

              My Spring related question is: Is there anything in the Spring IoC container that would provide pooling and load balancing services to the plain java MessageListeners when running in a cluster (multi-JVM, multi-machine logical and physical cluster)?

              I have my own idea how could we utilize web container services to bring pool, and instance management to Spring, but my question is - does Spring already have it?

              Regards,
              Edmon Begoli
              We've finally got there. Spring based message driven POJOs which allows you to get the benefits of MDBs but from inside any Spring deployment (stand alone, inside Tomcat etc).

              For details try this page...

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

              We've not currently tested XA works, but for non-transacted messages its currently working fine.[/i]

              Comment


              • #8
                We've finally got there. Spring based message driven POJOs which allows you to get the benefits of MDBs but from inside any Spring deployment (stand alone, inside Tomcat etc).
                Thanks James. I'll give it a try, and if everything goes according to my plans with Spring and JMS I will post some "HOW TO" examples.

                If you have some helpful pointers or examples please send them my way.

                Regards,
                Edmon

                Comment

                Working...
                X