6 Replies Latest reply on Apr 1, 2008 11:01 AM by timfox

    question with rollback/redelivery semantics

    rlucente

      I have an application with multiple consumers and multiple queues in a many to many mapping. The queues are polled by scheduling the consumers at a fixed delay. Each consumer reads a message and attempts to send an http request to a remote endpoint. If the remote endpoint is unavailable or some other error occurs, the consumer calls rollback and then it or another consumer tries again later. Each consumer has its own session.

      What I'm observing is that the rollback/redelivery semantics associate the undelivered messages with a particular consumer/session. If that consumer is destroyed, so are its rollbacked messages. Once rollback occurs, the consumer/session that rolled back is the only consumer that can see the messages.

      I really want the ability to:


      read messages from the queue
      attempt to contact an external system
      if that fails, put the messages back on the queue
      another consumer can see and process the messages


      I'm using JBoss Messaging 1.2.0 SP1. My company recently obtained JBoss EAP 4.3, which I believe bundles JBoss Messaging 1.4.0, but I won't be able to use that as part of my current delivery.

        • 1. Re: question with rollback/redelivery semantics
          timfox

          If a consumer is closed (is that what you mean by "destroyed"?), before the session is acknowledged, then the messages won't be visible to any other session until the session commits/rolls back.

          This is normal JMS operation.

          Can you be more specific about

          a) What you are doing

          b) What you expect to observe

          c) What you actually observe

          Also please mention whether you are using MDBs.

          • 2. Re: question with rollback/redelivery semantics
            rlucente

            Ok, I'm using the Apache Muse product to build a WS-Notification 1.3 based message broker. JBoss Messaging is used as a message store to buffer messages between senders/receivers. Clients can publish and subscribe using the web services offered by Muse. When a message is published to the system, Muse determines the client endpoints that should receive the message. These messages are written to client specific JMS queues for eventual delivery. A separate thread pool has periodically scheduled client delivery tasks that, within a single transaction, read messages from a client-specific queue and then attempt to deliver a batch of messages to the client using the WS-Notify SOAP message. If the delivery fails (client unavailable) the transaction is rolled back. Use of the thread pool results in different threads attempting delivery to the remote endpoint, so I use a thread local variable to cache the session and a map of session to messageconsumer for each client delivery task. JMS is providing time-to-live, prioritization, and message persistence.

            I modified the DefaultMaxDeliveryAttempts to -1 to prevent rollbacks from causing messages to be sent to the DLQ.

            The rollback semantics are where questions arise. When I rollback, the messages appear to be marked for redelivery only by the messageconsumer that read them. The messages are not visible to other messageconsumers at that point.

            I believe I attempted closing the consumers and then rolling back the session, but that seemed to destroy the messages instead of replacing them on the queue.

            I hope this gives a more complete picture of what I'm attempting to do.

            • 3. Re: question with rollback/redelivery semantics
              rlucente

              I am not using MDBs.

              Also, Ray Ploski, RedHat/JBoss, was at my company location back in September for a week to review the implementation and help with performance optimization.

              • 4. Re: question with rollback/redelivery semantics
                timfox

                If you have consumed messages via a message consumer and then roll back, the same session will receive the same stream of messages.

                This behaviour is as specified in the JMS spec. (1.1, sectons 4.4.7 and 4.4.11)

                If you have the same message consumer(s) open on that session, then it will receive the same messages.

                BTW I would strongly recommend you upgrade to 1.4.0. A lot has changed since 1.2.0 :)

                Hope that helps.

                • 5. Re: question with rollback/redelivery semantics
                  rlucente

                  I read the JMS spec but I didn't really see the description of a session/message affinity at rollback.

                  Regardless, sessions are not thread-safe so using a thread-pool is an issue because it requires I have multiple sessions, only one of which can see its recently rolled back messages.

                  We just received the support contract for JBoss EAP 4.3, so I'll be working with 1.4.0 over the coming weeks.

                  Thanks for the quick reply.

                  • 6. Re: question with rollback/redelivery semantics
                    timfox

                     

                    "rlucente" wrote:
                    I read the JMS spec but I didn't really see the description of a session/message affinity at rollback.


                    4.4.7:

                    "... If a transaction rollback is done, its produced messages
                    are destroyed and its consumed messages are automatically recovered. For more information on session recovery, see Section 4.4.11 �Message
                    Acknowledgment.�

                    And

                    4.4.11:

                    "A session’s recover method is used to stop a session and restart it with its first unacknowledged message. *** In effect, the session’s series of delivered messages is reset to the point after its last acknowledged message ***. ..."



                    Regardless, sessions are not thread-safe


                    True. If you do use a session between multiple threads all sorts of strange things might start to happen