Open ptusch opened 5 years ago
I've pinpointed the issue down to the ackBatch processing. Since my usecase uses the batchAacking, I have an interval that fires each 500ms.
So imagine using msg.reply
before and the next msg.reply
after the batch processing, you end up in invalid states. The messages
count is down to 0 and further acks will not be performed, resulting in unacked messages.
A better workaround (though, requires code change) is to remove the raw.ack()
call and call msg.ack()
in your business logic.
I wad able to fix the issue. It's a bit disgusting but what can I say. It's working. Please have a look if you feel like it: https://github.com/hufsm/rabbot/pull/21/files#diff-25b7d53c91b664dd589db8a4e4e02119
When you work with the rpc feature of rabbot, you may be tempted to use the intermediate callback and
more
option. If you do that (or plan to do that) be prepared to have a bunch of unacked messages in your queue. There seems to be some weirdness that invalidates previously performed acks. It's a bit hard to explain, please have a look at the attached examples.A workaround would be to use the
noAck: true
option upon consuming things. Of course, this may break your workflow so be vary.