activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chase Seibert <>
Subject RE: uncommitted transactions preventing queue processing
Date Fri, 08 Dec 2006 14:40:33 GMT

The suggestion I'm leaning twoards is to simply spawn many consumer threads so that if some
go into a "waiting" state for a redelivery, the over-all queue will keep processing. However,
I see some problems with this model that I'm not sure how to solve. Namely, I'm not sure how
to create multiple consumers with sessionTransacted = true.


Perhaps this is a Spring issue and not an ActiveMQ one. My testing so far shows that the DefaultMessageListenerContainer
settings sessionTransacted = true and concurrentConsumers > 1 are somewhat mutually exclusive.
It seems that when the session is transacted, there is effectively only one consumer. Other
consumer threads are spawned, but only one is allowed to enter the onMessage() block at once.
Maybe the confusion is on my part; it seems that sessionTransacted is treating the entire
queue as transacted, when my real goal is to have the individual messages be transacted. 


If I could implement transacted messages with a configurable number of consumers, that would
help somewhat. But I would still be worried about a high volume of redelivery messages choking
out ones that would be successful on the first run. I could easily fill 100 consumer threads
with redelivery attempts when there are thousands of messages queued that could be delivered
on the first shot. My initial design was to do redelivery on 1/5/15 minute cycles, which would
make this even more likely.


If I cannot use sessionTransacted, then I will have to fall back to untransacted messages,
at which point I can't use a redelivery policy at all (they only go into effect on a rollback).
I would implement a queue for each redelivery attempt (maybe 2 or 3 of them), and simply put
a Thread.Sleep(x) as the first step in each onMessage() processor to do the redelivery delay.


The deeper I go down that path, the more it seems like ActiveMQ is not the right tool for
the job. Either that, or I'm not understanding something; which is entirely possible. 




Application Developer


Staffing and Recruiting Software On Demand 

The Last Software You'll Ever Need

33-41 Farnsworth Street, 5th Floor, Boston, MA 02210


-----Original Message-----
From:James Strachan 
To: "" <>;
Sent: Dec 8, 2006 05:03:44 AM
Subject: Re: uncommitted transactions preventing queue processing

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. 



  • Unnamed multipart/mixed (inline, None, 0 bytes)
    • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message