[rabbitmq-discuss] Lose messages between restarts of broker

[Emile Joubert]

Hi Rudi,

Op 28/10/2010 19:50, het Rudi Wirth geskryf:
>> If you really need messages to go safely to disk, then you should
>> put the channel into transactional mode (tx.select), and issue a
>> tx.commit
>
> What about unacknowledged messages?
>
> A Producer (rabbit 2.1.1 java client, not Spring Rabbit AMQP) commits
> some persistent messages on a durable queue/exchange.
>
> The Consumer is neither ack'ing nor rejecting the message to leave it
> on the queue (and let recovery retry it later), but I am committing
> periodically, e.g.:
>
> QueueingConsumer.Delivery delivery = consumer.nextDelivery(); //
> neither channel.basicReject or Ack channel.txCommit();
>
> Per ctl:
>
> $ rabbitmqctl list_queues name messages messages_unacknowledged
> messages_ready Listing queues ... testQueue       5       5       0
>
> Using a soft "rabbitmqctl stop", a Broker restart will make the
> unacknowledged messages ready again (as expected). testQueue       5
> 0       5
>
> With a Broker hardkill, the unack'd messages disappear. testQueue
> 0       0       0
>
> For our implementation, I was going to rely on unacknowledged
> messages, flow control (qos) and periodic channel.basicRecover() to
> implement a crude, controlled "delayed retry" behavior, without using
> a temporary parking queue or application-provided intermediate
> storage. Not that anyone would kill the broker but is there a way to
> flush unack'd messages to disk?

The advice that Matthew gave applies to unacknowledged message too. If 
the publisher commits on a transacted channel then persistent messages 
in a durable queue are guaranteed to be on disk up to the point when 
they get removed from the queue. This includes any period that messages 
spend in an unacknowledged state.

In your example, had the publisher made the channel transactional and 
committed the messages, all unacknowledged messaged would be in the 
ready list after a hardkill.

There is no direct way for a consumer to affect the persistence of a 
published message other than to republish it as a new message with 
different parameters.

Regards

Emile