|| at Jan 29, 2010 at 3:51 pm
No. Given that the transport is reliable, there is no good reason for a
client to issue the same ack more than once. If it does then that
probably indicates a bug in the client code. So with the restriction in
place the server can tell the client that it's probably doing something
Well, maybe it's a little wrong :) The messages in my system are
handled asynchronously, and once the work associated with some number
of messages is done, I want to ack them. I can't use the rabbit
channel from the thread that does the processing, so I have a
workaround that has a possiblity of multiple acks on the same tag.
I'm guessing I can come up with a cleaner solution though. I suppose
maybe the cleanest way to handle this would be to wrap
QueueingConsumer in a class that mantains a list of dtags that need
acking, so whenever the consumer gets a message (or times out) it acks
the messages at once. I think I'll do it that way; it seems a lot
cleaner that what I'm doing now.