[rabbitmq-discuss] Consequences of not ACK-ing

[Bell, Paul M.]

All,

In putting together a system architecture that tries to leverage Rabbit, I decided that I'd best not wait until end of March to get Alvaro and Jason's book. So I yesterday got the MEAP version and last night began reading it.

I came across something that is, at first blush, a fly in the ointment. Specifically, I read that if a consumer doesn't ACK (and assuming no auto-ack), then the broker will NOT deliver another message to that consumer, until it does ACK the previous message.

My consumers quickly hand-off the work task represented by the message. That is, they quickly dispatch a message to other threads which can carry on asynchronously. And then they are ready to receive another message. I had assumed and hoped that Rabbit would simply keep delivering messages despite this lack of ACK. This would allow me to maintain a high level of paraellism from the consumer "downwards." But it would also give me a means by which, should a work task fail, its message could be redelivered and the task retried.

A few questions:

a. can this behavior on the part of the broker be circumvented?

b. any ideas on ways of achieving my intent?

In re (b): I am beginning to think that my only choice (assuming answer to (a) is "no") will be to ACK the message as soon as I can. And, in my architecture, this would mean that I would need to create in the persistence layer some kind of task "status record" that records task state (e.g., "in-flight", "failed" "succeeded"), AND that the retry mechanism would have to depend on visiting the persistence layer to obtain the status record and take the appropriate action based on the last recorded task status. It seems to me it would be much easier if the message were still in a queue and could be redelivered from "above."

Thanks for your help.

-Paul



ATTENTION: -----

The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other  confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control.