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:
- 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.
- 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.
- 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.