[rabbitmq-discuss] unacknowledged messages lost after broker kill, despite consumer txCommit and noAck
rwirth at demandware.com
Fri Oct 29 19:46:58 BST 2010
Sorry on the repeat post from the "Lose messages between restarts of broker"
> 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,
QueueingConsumer.Delivery delivery = consumer.nextDelivery();
// neither channel.basicReject or Ack
$ rabbitmqctl list_queues name messages messages_unacknowledged
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?
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.
More information about the rabbitmq-discuss