[rabbitmq-discuss] AMQP 0.9.1 Specification: Suport for Deliver API

Mon Feb 7 10:10:50 GMT 2011

Hi Prashant,

On 06/02/11 21:00, Prashant wrote:
> Helo,
>
> 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:

  http://www.rabbitmq.com/specification.html

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.

Regards

Emile