[rabbitmq-discuss] AMQP 0.9.1 Specification: Suport for Deliver API
emile at rabbitmq.com
Mon Feb 7 10:10:50 GMT 2011
On 06/02/11 21:00, Prashant wrote:
> I was stuck while trying to use deliver option in channel. Now , in my
> experiment , I am trying to use basicRecover to republish all the
> unack messages back to the channel. These messages gets again repub ,
> so far so good. But i fear , it might go into a loop as ,when Consumer
> cannot consume messages it will be returned back to channel.
> I looked into Spec refrence and found out that channel has a deliver
> mechanism , which basically checks for relivered bit .
> Per specification-----
> This method delivers a message to the client, via a consumer. In the
> asynchronous message delivery model, the client starts a consumer
> using the Consume method, then the server responds with Deliver
> methods as and when messages arrive for that consumer.
> * The server SHOULD track the number of times a message has been
> delivered to clients and when a message is redelivered a certain
> number of times - e.g. 5 times - without being acknowledged, the
> server SHOULD consider the message to be unprocessable (possibly
> causing client applications to abort), and move the message to a dead
> letter queue.
> Now , my question is how I can leverage this , i.e. if messge is
> redelivered 5 times to channel , I intend to publish a message about
> the status of this message with specifics that it has been failed
> after trying 5 times...
> If , its pssible , where do I need to add the logic to check this,
> certainly now publisher as the messages are in channel.Can you please
> throw in some pointers.
The specification does indeed suggest that a broker should track the
number of redeliveries. You can get more details about conformance for
this feature on the specification page:
The feature that you describe has reference "basic / deliver / 01" and
is mark as "planned", which means that it has not been implemented yet.
It is possible to get similar functionality without broker support though.
A possible way to deal with your scenario is to republish
non-processable messages to a different queue instead of leaving them
unacknowledged. You might even republish messages together with the
cause of failure to aid the decision about their fate.
Another option might be to publish messages initially with a processing
count of 0. Each time a consumer fails to publish the message, republish
the message to the same queue with an incremented processing count
instead of leaving the message unacknowledged. When the processing count
reaches 5 then you can take appropriate action.
More information about the rabbitmq-discuss