[rabbitmq-discuss] RabbitMQ 2.7.0 is released

Tue Nov 22 07:12:44 GMT 2011

I wasn't my intent to trigger a bug report, only to understand what the
intended behavior is.

As far as I understand it so far, the new behavior is designed to keep as
much ordering in the queue as possible, whereas the old behavior was to
simply move the rejected message to the end of the queue.

For us, this change is rather unfortunate.

The most common scenario for rejects in our messaging layer is that we want
to process it at some later time, because some external service needed to
process the queue is currently unavailable, or we know some other consumer
is already processing a copy of a redundantly queued message.

See http://xing.github.com/beetle/

With the new behavior, a consumer will immediately see the rejected message
again, even though there might be hundreds of messages in the queue which
could be processed right away.

I think the new behavior is also very surprising given the name of the
parameter to reject is "requeue".

Could you please explain what motivated the change?

Frankly, we'd prefer to get the old behavior back.

-- stefan

Am 19.11.11 23:27 schrieb "Matthias Radestock" unter
<matthias at rabbitmq.com>:

> Stefan,
> 
> On 19/11/11 05:52, Stefan Kaes wrote:
>> it appears that the FAQ page describing the new reject semantics has
>> disappeared.
> 
> Indeed it has.
> 
>> Here's my current understanding:
>> 
>> Let's say we have a message queue containing messages<m2, m1>, where m1
>> will be delivered next.
>> 
>> Let's further assume we have a prefetch count of 1 on our single consumer,
>> which is subscribed to the queue.
>> 
>> Then, if the consumer rejects the message, it will be resend to the consumer
>> before m2 is sent, right?
>> 
>> In other words: from a consumer perspective, "reject(requeue=true)" behaves
>> exactly like "recover" in the scenario above.
>> 
>> Correct?
> 
> The second message the consumer receives could be either m1 or m2.
> Arguably that is surprising behaviour so I will raise a bug to look into
> this.
> 
> Regards,
> 
> Matthias.
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

Dr. Stefan Kaes
Principal System Architect

XING AG
Gaensemarkt 43, 20354 Hamburg, Germany
Tel. +49 40 419131-801, Fax +49 40 419131-11

Commercial Reg. (Registergericht): Amtsgericht Hamburg, HRB 98807
Exec. Board (Vorstand): Dr. Stefan Groß-Selbeck (Vorsitzender), Ingo Chu,
Dr. Helmut Becker, Jens Pape;
Chairman of the Supervisory Board (Aufsichtsratsvorsitzender): Dr. Neil
Sunderland

Please join my network on XING: http://www.xing.com/go/invite/Stefan.Kaes

This email may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this email in error) please
notify the sender immediately and destroy this email. Any unauthorized
copying, disclosure or distribution of the material in this email is
strictly forbidden and may be unlawful.