On 7 Dec 2006 16:52:42 -0500, Chase Seibert <[EMAIL PROTECTED]> wrote:
*** Caveat: We are in the process of implementing our first ActiveMQ project, and we may be missing some basic configuration. *** Our research shows that with ActiveMQ, transacted messages queued after the currently processing message will not get dequeued until that first transaction is committed.
Yes. The current message must be processed & replayed until its replay counter is reached on which time its then failed back to the broker
This remains true even if the current transacted message has failed once and is pending redelivery. No other messages are processed until the first redelivery is successful, or the maximumRedeliveries threshold is reached.
Yes. If this were not the case then queue ordering would be broken as soon as a redelivery occurs.
Our scenario involves transacted messages that do not necessarily need to be processed in the order they were inserted onto the queue. In other words, if a message listener throws an exception on a particular message, we still want the messages behind that one to get processed immediately.
Either set a prefetch value of 1 (so no consumer gets more than one message at once) or set the maximum redeliveries to 1 to avoid a bad message blocking the next one behind. But if you don't care about order - why not just run lots of consumers so its not a big deal if one consumer replays a bad message a few times?
The explanation on that issue was that ActiveMQ preserves the order of the queue. In this case, subsequent messages cannot be processed until a previous one is committed in order to maintain the message order. In contacting the poster of that issue, the resolution was to use a secondary queue to reprocess failures.
So a message that fails to be processed correctly is replayed a configurable number of times until it is processed correctly - if it fails to be processed correctly after all the redelivery attempts its placed on a dead letter queue for processing later on. You don't really need to put your own secondary queue system in place. -- James ------- http://radio.weblogs.com/0112098/
