Uploaded image for project: 'ActiveMQ Artemis'
  1. ActiveMQ Artemis
  2. ARTEMIS-3093

Message Order broken with Core Protocol when rolling back transactions

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Critical
    • Resolution: Fixed
    • 2.16.0
    • 2.18.0
    • Broker

    Description

      ARTEMIS-2458

      This issue still persists.

       

      Consuming from a queue with two threads with distinct sessions while rolling back directly in each thread when receiving a message breaks the whole order of the queue. Even with delays of 500ms.

      The queue/addresse is configured as ANYCAST queue.
       

      (In 2.10 this issue persists as well.)

      Basic Test setup is like this:
      You have a non-clustered single instance of Artemis.
      You do have a redelivery-delay of 0.

      You fill an anycast queue with 1000/10000 ordered messages.
      You disconnect your producer and start the two or more consumers that try to fetch all of the messages from that exact same queue, but can only get one, as you always roll back the session.
      Each time any of those two(or more) consumers receives a message, they rollback the session instantly and sleep 0 to 500 ms.

      After rolling back every time you receive a message on any of your consumer threads, you expect to always get the message with the content "0".
      After like ten iterations of this ping-pong rollback between your two consumer threads, you start to get completely random messages, not even within the range of 0 through 10, but completely arbitrary ones from within the queue.

      You disconnect your consumers and try dumping the queue. You get a completely unordered message queue.

      Attachments

        Issue Links

          Activity

            People

              clebertsuconic Clebert Suconic
              behm015 John Behm
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0h
                  0h
                  Logged:
                  Time Spent - 1h 40m
                  1h 40m