[rabbitmq-discuss] unacknowledged messages lost after broker kill, despite consumer txCommit and noAck

[Marek Majkowski]

On Fri, Oct 29, 2010 at 19:46, rjwirth <rwirth at demandware.com> wrote:
>> 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 even after I have
> just committed the channel
>  testQueue       0       0       0
>
> Is there anything to commit on the channel if the Broker didn't get an Ack?
> Shouldn't the "lease" of the message be at least committed?

Hi,

Maybe I missed something, but I'm not able to reproduce your results.
1. I publish 5 persistent messages in a transaction (tx_select, tx_commit).
2. I receive all of them, with no_ack=False and not acknowledge manually.
3. Restart the server.

For both, hard kill and `rabbitmqctl stop` I'm able to see the messages after
rabbit is up again.

Did I get everything right?

Cheers,
  Marek