4 Replies Latest reply on Nov 14, 2007 7:11 AM by mclu

    FIFO Ordering also if Rollback (Retry)?

    mclu

      Hi again!

      At our project the order of the messages is important.
      For that we configured the listener (MDB) as a SingletonMDB (maxMessages and maxSession is set to "1").

      But in cases of a (network or handling) failure the message is marked as retry. New messages which arrived in between are processed BEFORE the other message retries. So the order is scrambled.
      Is it possible to configure a real FIFO also in case of retry? I think the order issue is a common requirement.

      I only want to stop the queue processing as long as the message can be delivered or I decide via timeToLive or in my code that this message can be dropped.

      Is this already possible or is this in the pipeline/feature request?

      Greets Markus Lutum / Germany

      PS: I do not want to discuss the design of my clients application. Its historical grown. But I want to get rid of all the self implemented Queues with persistent storage and there BUGs :-)

        • 1. Re: FIFO Ordering also if Rollback (Retry)?
          timfox

          If you use a straight JBM consumer, and only have one consumer per queue, then order should be preserved on rollback.

          However I don't think things are so simple with MDBs, since AS MDB layer maintains a buffer of messages ready to send to MDBs.

          I would need to look into this further, but maybe would need changes outside JBM in the AS.

          BTW the JMS spec does not require message order to be preserved after rollback.

          • 2. Re: FIFO Ordering also if Rollback (Retry)?
            mclu

            Thx Tim!

            I saw the Jira entry
            http://jira.jboss.com/jira/browse/JBAS-2444
            about the ordering issu and a Link to Messaging.

            But anyway.
            Does your explanaition mean that after a NACK/Transaction Rollback of my single JBM Consumer the Message is put back to the queue and is retried after the set time?
            Example:
            Lets assume message A, B and C in the Queue. All with same prio and a single consumer. Retry Interval is set to 20 seconds.

            Needed behaviour
            consume A (ok)
            consume B (NOK/Transaction roll back)
            consume B again after 20 sec (NOK/Transaction roll back)
            consume B again after 20 sec (Now processing is OK- Commit)
            consume C

            The behaviour with my singleton MDB is currently:
            consume A (ok)
            consume B (NOK/Transaction roll back)
            consume C
            consume B again after 20 sec (NOK/Transaction roll back)
            consume B again after 20 sec (Now processing is OK- Commit)

            Greets
            Markus

            • 3. Re: FIFO Ordering also if Rollback (Retry)?
              timfox

               

              "mclu" wrote:
              Thx Tim!

              I saw the Jira entry
              http://jira.jboss.com/jira/browse/JBAS-2444
              about the ordering issu and a Link to Messaging.


              Yes, that feature is implemented in JBM.


              But anyway.
              Does your explanaition mean that after a NACK/Transaction Rollback of my single JBM Consumer the Message is put back to the queue and is retried after the set time?
              Example:
              Lets assume message A, B and C in the Queue. All with same prio and a single consumer. Retry Interval is set to 20 seconds.


              Ok, you didn't mention you were doing _delayed_ redelivery.

              The ordering only applies to normal redelivery (i.e. not delayed).

              Guaranteeing ordering with a delayed redelivery would be even more complicated since we'd have to block any other messages that arrived in the intervening period being delivered.

              It is possible though - you could add a feature request if you like :)



              • 4. Re: FIFO Ordering also if Rollback (Retry)?
                mclu