activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: uncommitted transactions preventing queue processing
Date Fri, 08 Dec 2006 10:02:55 GMT
On 7 Dec 2006 16:52:42 -0500, Chase Seibert <> 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

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.



View raw message