No subject

Sun Jun 17 23:12:48 BST 2012

i realized that I can only send ACKs from the original connection/channel
that was used to receive a message. This sorta blocks me from implementing
the use/case I wanted. Here is the scenario:

- Publisher sends a message to RabbitMQ queue (via exchange using routing
key and binding).
- Subscriber gets the message. It doesn't ACK immediately because message
processing involves database operation. If database operations goes well,
then ACK will be sent. If database operation fails, no ACK will be sent and
message will be redelivered later (which is great, because I want to retry
the operation).
- Database operation goes through and the subscriber tries to send ACK.
Immediately before that, RabbitMQ host becomes unavailable and ACK doesn't
go through (I get the exception, so I am notified that ACKing failed).
- My operation is not idempotent right now, so when another subscriber
connects to RabbitMQ (after it becomes available), the same message will be
redelivered to it (because ACK didn't go through). This will cause
duplicated operations, because original message was never ACKed properly.

I wanted to save ACKs to disk and then recover them (send them to RabbitMQ)
before new connections from subscribers are made. However, from the link
above it seems that this is not possible with RabbitMQ? Is there a way for
me to implement this or should I treat ACKs differently? If ACK should only
indicate if message transfer was okay, then I suppose using autoacking
feature (when consumer is initialized setting noAck parameter to true) is
better than doing it manually. In that case, is there a way for me to
request redelivery of this message from Rabbit even though it was previously
ACKed?

Thanks a lot for your time!
Milan 

--
View this message in context: http://rabbitmq.1065348.n5.nabble.com/What-is-a-proper-workflow-for-ACKs-tp21995.html
Sent from the RabbitMQ mailing list archive at Nabble.com.