Uploaded image for project: 'FUSE Message Broker'
  1. FUSE Message Broker
  2. MB-381

Consumed messages re-appearing in the broker

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Blocker
    • Resolution: Done
    • Affects Version/s: 5.1.0.0-fuse
    • Fix Version/s: 5.0.0.20-fuse
    • Component/s: broker
    • Labels:
      None
    • Environment:

      Tested on Windows, using JDK 1.6.0_07, but probably a problem on all platforms since it is a clear logic problem.

      Description

      This is probably more of a problem with how the broker recovers from failures in conjunction with the database rather than a core broker failure.

      The attached project clearly shows the problem where messages which have been consumed may re-appear after the broker restarts from a kill -9, forced kill in Windows, or a stop in the eclipse environment.

      To run the test case in eclipse:

      1. Run the JUnit test: SpringActiveMQTest.java (Explanations are given in comments of the test case) and let it run about 1 minute. It will shut-down automatically for a graceful shut-down.
      2. Run the Java main class: SpringActiveMQ.java. Start jconsole from jdk6 on url: service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi. As you can see, there is only 1 message on the queue, as expected from the test. Kill the broker with the stop button of eclipse.
      3. Again, run the Java main class: SpringActiveMQ.java. It will force ActiveMQ to recover. Start jconsole from jdk6 on url: service:jmx:rmi:///jndi/rmi://localhost:1099/jmxrmi. As you can see, there is 2 messages on the queue. One message re-pop. Explanation is given in comments of the junit test.

      This is due to the fact that the deletion of a message was stored in a data file that is archived, but the fact that the message was sent to the broker is stored in another data file that remains active. So when the broker restarts it doesn't realise that the message was already removed and adds it again.

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                garytully Gary Tully
                Reporter:
                martinmurphy Martin Murphy
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Due:
                  Created:
                  Updated:
                  Resolved: