[rabbitmq-discuss] Redelivery of unacknowledged messages

[Ben Hood]

Jonatan,

On Thu, Oct 2, 2008 at 1:48 AM, Jonatan Kallus <jonatan at heysan.com> wrote:
> Is it meant to work like this or is it a matter of a feature not being
> implemented yet?

The real problem that you have here is that the Basic.Reject command
as specified in the AMQP protocol is not implemented in RabbitMQ :-(

There is a compatibility matrix here: http://www.rabbitmq.com/compatibility.html

The reason was because the reject behaviour specified in 0-8 of the
spec was a bit tricky. Also we have only been asked by one other
person to implement this functionality, hence it has been
de-prioritized.

However, it is a roadmap item, because we want to be fully spec
compliant after 0.91 is signed off.

I can't give you an ETA on this feature, it will get done when time
and resources permit.

In the meantime, the example I posted previously is just a workaround
for the lack of Basic.Reject.

> In my current implementation I am closing the channel occasionally, for no
> particular reason, but to get the redeliveries. This causes the processing
> to temporarily stop or slow down since I have to wait for all tasks to be
> done and acked before I can close the channel. (Since messages need to be
> acked on the same channel they were received on, as far as I know.)
>
> It would probably be possible to have two parallel channels open, one active
> (receiving new tasks) and one waiting for its tasks to be done and acked,
> then closing the inactive one, making the previously active one passive and
> opening a new active channel. This would add the complexity of keeping track
> of what message that should be acked on what channel.

Yes, it's clunky. A good solution would be to convince us to implement
this feature :-)

> Are there any good patterns to handle this?

Maybe you can describe the specific use case that requires you to have
redeliveries before we talk about strategies to deal with them.

Ben