Hi, bumping this one... Has this (I'd have to say major) issue been addressed in newer versions of ActiveMQ?
Jason Rosenberg wrote: > > All, > > I have been experimenting with using exponentialBackOff as a redelivery > policy. I have multiple parallel consumers. I'm using AMQ 4.1.1, using > Spring's DefaultMessageListener, within Tomcat 6. > > I've noticed that when a message consumer has a failure, and throws an > exception, and the message gets scheduled for retry, the particular > consumer thread gets tied to the redelivery, and it doesn't process any > more messages until it's gone through the full redelivery schedule for the > error prone message. So, with the exponentialBackOff mode, it's easy to > set it to wait 10 minutes before redelivering a failed message, and in > that time that consumer will be blocked. > > If the consumer has a pre-fetch greater than 1, this means other messages > which might be perfectly valid for processing are blocked until the > troubled message goes through it's full redelivery cycle (which could be > infinite!).... > > I'm wondering if there's an alternate way to configure things, so that a > message marked for redelivery goes back on the queue to be scheduled by > the next available consumer (and not until it's next scheduled redelivery > time has arrived!).... > > If I have a queue with multiple consumers, and perhaps even a small > percentage of the messages are corrupt and force multiple retries, it > could eventually happen that all consumers are blocked waiting idly to > retry the message at the top of it's list, even though other messages are > readily available. This would seem to be the case even when the prefetch > limit is 1. > > Thoughts? > > Jason > -- View this message in context: http://www.nabble.com/Redelivery-sticks-to-and-blocks-a-consumer-thread-tp13261850s2354p17691674.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.