Issues with AMQP guaranteed delivery
From Sebastian Latza <mail@sebastian-latza.de>:
Hi everybody,
I'm currently using Akka to realize a framework which takes messages out of a RabbitMQ instance and generates HTTP request from these messages.
One issue I now have encountered with akka-amqp is that the MessageConsumer implicitly acknowledges messages it receives, which then get forwarded to the "real" consumer actor. If the consumer dies, the enqueued message in its mailbox silently get lost. To avoid this situation, I have implemented a rather trivial solution which requires explicit ACK messages by the consuming actor. [1]
While this adds some additional reliability, it introduces other problems. If the consuming actor fails to acknowledge messages the MessageConsumer will lock up after a while. This again could be countered by a scheduler managing timeouts on the ACK messages or maybe even futures, but none of those solutions I have come up with seem to be very elegant. I'm not familiar with supervisor hierarchies, but maybe there is a solution there. If somebody can provide any pointers or ideas how to solve this problem properly I'd be happy to provide the implementation.
Regards
Sebastian
[1] http://github.com/slider/akka/commit/9a5f36ba9e4a6c7116aaf2d75acb99db097b7619
Hi everybody,
I'm currently using Akka to realize a framework which takes messages out of a RabbitMQ instance and generates HTTP request from these messages.
One issue I now have encountered with akka-amqp is that the MessageConsumer implicitly acknowledges messages it receives, which then get forwarded to the "real" consumer actor. If the consumer dies, the enqueued message in its mailbox silently get lost. To avoid this situation, I have implemented a rather trivial solution which requires explicit ACK messages by the consuming actor. [1]
While this adds some additional reliability, it introduces other problems. If the consuming actor fails to acknowledge messages the MessageConsumer will lock up after a while. This again could be countered by a scheduler managing timeouts on the ACK messages or maybe even futures, but none of those solutions I have come up with seem to be very elegant. I'm not familiar with supervisor hierarchies, but maybe there is a solution there. If somebody can provide any pointers or ideas how to solve this problem properly I'd be happy to provide the implementation.
Regards
Sebastian
[1] http://github.com/slider/akka/commit/9a5f36ba9e4a6c7116aaf2d75acb99db097b7619
Leave a comment
on 2010-07-19 15:15 *
By Irmo Manie
My guess is that this is already fixed on current master.
Manual ack is supported and failing to do ack means you have to let the actor die to have supervision kick in and kill the channel, so un-acked msg is re-queued.
See: http://groups.google.com/group/akka-user/browse_thread/thread/6dc9be73ac0d62c8/614eb99514d26179?lnk=gst&q=amqp#614eb99514d26179
Manual ack is supported and failing to do ack means you have to let the actor die to have supervision kick in and kill the channel, so un-acked msg is re-queued.
See: http://groups.google.com/group/akka-user/browse_thread/thread/6dc9be73ac0d62c8/614eb99514d26179?lnk=gst&q=amqp#614eb99514d26179
Irmo, what are your thoughts on this one?
Fix or invalidate?
Can you take it?
Fix or invalidate?
Can you take it?
This is fixed in previous release.