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

[Emile Joubert]

Hi Prashant

The idea behind the counter is to terminate any further processing and 
prevent an infinite loop.

It is not possible to alter a message when rejecting. The closest you 
can get is to consume the message and publish a new message containing 
the changes you need.

Regards

Emile

Op 07/02/2011 22:25, het Prashant geskryf:
> Hi Emile
>
> I tried second approach of yours , but the issue with the approach is
> that republishing of message goes into recursive publishing.
>
> A publish to Q where my consumer check if header has count and if not
> =5 update and republish ( this republish , shoudl be rather
> reject(requue = true ) ).
>
> so that set me wondering whether we can alter header of a message and
> requeue it back rather than republishing it ?
>
> Regds
> Prashant
>
>
> On Feb 7, 10:10 am, Emile Joubert<em... at rabbitmq.com>  wrote:
>> 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.