[rabbitmq-discuss] Workaround for basic reject...
matthias at lshift.net
Sun Jun 7 21:03:25 BST 2009
Arun Suresh wrote:
> i dont want messages to be requeued until I am sure the consumer has
> a problem while processing them..
If the consumer hasn't started processing the messages, why do you care
if they get requeued and delivered to another consumer (or the same
consumer when it reconnects)?
If, otoh, the consumer is processing up to n messages in parallel, then
in the event of an error just wait for the processing of the remaining
n-1 messages to finish before ack-ing the successfully processed
messages and closing the channel.
> for the time being.. i have this workaround...
> I have 5 Channels open on the consumer node (each with a prefetch of 1..
> ).. so if the consumer has problem with any one message, I need to close
> just that channel where the message came from... ofcourse, this would
> mean that the message might get resent to another channel on the same
> consumer node... but im still debating over whether thats a bad thing
> within the context of our application...
> do you think, generally speaking, this a good idea ?
I can't see anything wrong with that approach.
> oh.. and by the way.. does setting prefetch to 1 just the same as not
> using basic.qos ??
Without basic.qos there is no prefetch limit, so the server will just
keep sending messages down the channel whenever it can.
More information about the rabbitmq-discuss