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

[rjwirth]

Sorry on the repeat post from the "Lose messages between restarts of broker"
thread.

> 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?

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?

Thanks much!
-Rudi 

-----
Rudi Wirth

-- 
View this message in context: http://old.nabble.com/unacknowledged-messages-lost-after-broker-kill%2C-despite-consumer-txCommit-and-noAck-tp30088199p30088199.html
Sent from the RabbitMQ mailing list archive at Nabble.com.