Broker cleanup on startup/shutdown
Looking for some details on observed behaviour with the 3.6 Broker.
We've been seeing some odd stuff in our production broker this week -- old transactions (using imqcmd list txn) that we can't get rid of, "phantom" messages in queues which just hang around and never get consumed and stuff like that. We had to bounce our production broker today because it seemed to slow and/or stop, and once the broker came back up, all the weirdness was gone -- no old transactions, no phantom messages.
Questions:
* does the broker do some kind of cleanup on startup? on shutdown?
* if so, is there any way to force the cleanup without bouncing the broker?
* does this imply that the broker isdesigned to be bounced every so often?
Can someone from Sun please reply? This behaviour is observed in our production broker and is causing us some pain. We need this thing to be highly available and so far, we're not seeing it. Mail me off list if you like.
[1002 byte] By [
kibitzer] at [2007-11-25 22:07:15]
# 1
The broker rolls back any in-process transactions at startup. The intention isn't to clean up normal transactions which have been committed, instead its purpose to clean up the state after a crash.
Unless you are running MQ with the Application Server, transactions should be cleaned up when the connection closes or the the transaction is committed. If you are running with a Sun's application server XA transactions (which are used by AS) may span multiple connections. This means that if the application server crashes (but the broker doesnt) some transactions may be left in limbo. These will only be cleaned up at a restart.
Uncommitted messages should not be redelivered, however listing the destination will show both the committed and uncommitted transactions (this confusing so it will be fixed when our next version is released).
If messages are laying around, it "should" be because the session associated with the transaction is still hanging around and the transaction was never committed (since those messages are in limbo).
NOTE: in 3.5 transactions were closed when the producer or consumer closed, this was not correct per the JMS spec so it was changed
If you are seeing something different happening - send mail to the mq-feedback@sun.com and we'll send you some debug commands to allow us to look @ the state of the broker when this happens
# 2
I realize I missed a question ...
There currently isnt a way to clean up transactions (unless they are XA transactions and are stuck in PREPARED) while the broker is running (we have an RFE to allow an administrator to force the rollback of an OPEN transaction - but it has not been implemented)
Bouncing the broker or killing the offending application (or connection) who is holding on to the messages is currently the only option.
However, messages shouldn't be getting stuck so my hope is that if we can track down what (on the broker or your application) is getting the messages stuck you wont need to force a cleanup
