Issue and question - Detached receivers / draining credits #412
Comments
|
Can you attach a simple reproducer? Or else a protocol trace/log of the interaction? Acknowledgement should be allowed after the detaching of the receiver. Whether the broker handles that is another question though. It may consider unacked messages at the point the receiver is closed as unconsumed. |
|
When you say protocol trace/log, do you mean from rhea, or my broker? (ActiveMQ in this case) |
|
Either should do. The key thing is to determine what the actual interaction is. |
|
Okay, turned on rhea debug logging, and scaled my service to two so there were two consumers on the queue. here are the logs from the service that consumed the message originally, showing the message being consumed, a sleep statement being executed, and then the Here is the other service that is consuming on the queue. Ends up picking up the message as soon as the other service detaches on the queue, which occurs at |
|
Does anything else happen on the first process after the receiver_close? My understanding of your issue is that you want to acknowledge the message received after that point. Is that happening here? (There is no disposition in that first log, but neither is there a session close or connection close, so from an AMQP perspective it is incomplete). My suspicion is that the broker will consider any messages unacknowledged at the point the receiver is detached to be available for redelivery. In that case, sending an acknowledgement after the detach is not going to have any effect anyway. (I can't confirm this without knowing what if anything happens with the first process after the detach). Regarding the other question, at present you can only successfully drain the credit if you have automatic credit management disabled. There is an example of that here: https://github.com/amqp/rhea/blob/main/examples/drain.js. |
|
Ah yeah, I accidentally cut off some logging at the end. I recreated it, and these were the rhea logs in the service that was shutting down The message is acked, then the queue is closed These are the logs from the second service that got the same message It does look like this particular consumer is disabling automatic credit management, but not sure about the rest of the services. That is good to know! Edit: Is it possible to mutate a consumer to disable automatic credit management, or is that only possible during consumer instantiation? |
|
Ok, the extra logs confirm that the broker is redelivering any unacknowledged message at the point that the receiver is closed. So acknowledgements sent after that are ignored. |
|
Is it possible to mutate a consumer to disable automatic credit management, or is that only possible during consumer instantiation? |
|
At present you can only set that on creation of the receiver. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Issue: Can't ack a message on a detached receiver.
I'm trying to allow messages that are being consumed (message sent / haven't been ack'd yet) during server shutdown.
I attempted to detach the receiver while it's processing, and waiting for it to complete before closing the queues / connection to Artemis. It appears though that calling
ack()in a detached state doesn't actually acknowledge the message, and the next consumer on the queue picks up the message that was being processed. Is acknowledging a message while in a detached state supported?Question:
If not, I would like to configure the consumers to stop consuming messages during shutdown, while it waits for pre-shutdown consuming to complete. How can I set the credits for the receiver to 0 so Artemis doesn't attempt to send any messages during shutdown? I see on the receiver interface there is a
drain_credit()function. Is that what I could call to prevent the consumer from picking up new messages?The text was updated successfully, but these errors were encountered: