Claude Moore wrote:What does *bad* and *good* mean in your use case ?
Henry Wong wrote:
I believe that consumers should be operating independently. Meaning that if a consumer is stuck on a message, the other consumers should still be working. The queue should not be blocked because of one consumer.
Claude Moore wrote:
In this hypothesis, there are more than one listener to a queue; I don't believe that a queue is locked (and doesnt' send messages to other listeners) if one consumer is stuck at one single message. Just think about
a queue used to distribute unit of work to different processors: it would be a severe limitation if queue were blocked. Or am I wrong ?
Pankaj Shet wrote:
Bad messages are those messages which throw exceptions while getting processed and by default, they are tried to be processed 6 or 7 times as per the default Redelivery Policy.
Good Messages are those messages which do not throw any exceptions and are processed successfully.
But when the bad messages are getting processed and are being retried, the processing of good messages is blocked..
i.e suppose if there are 10 messages in the queue, 1st message is processed successfully, 2nd message is processed successfully, 3rd message is processed successfully, but 4th message fails, while 4th fails what happens is, the 4th message is tried tried for redelivery 6-9 times at certain time period. suppose 10 seconds each, it will take 60 - 90 seconds to process that message, and if that processing is failed and that message moves to dead letter queue.
WHilw 4th message is being retried and redelivered, all the messages from 5th message onwards, have to wait for 60-90 seconds.
what is needed is that, those messages need not wait for the bad message processsing.
Will there be a chance that the message will get processed on redelivery?
If not, and it will fail every time, then this is a bad message. It can't ever be processed, why do you need ActiveMQ to redelivery so many times, when you know it will fail every time?
Just create an application specific "failed processing dead letter queue", and when a bad process occurs, send the message to the app specific dead letter queue, acknowledge the message as processed, and move on.
but it's quite enough when messages aren't part of a transaction - juat they are used to notify clients that events are occurred