Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MQ unacknowledged retries are not very multiprocess-intelligent #344

Open
natefoo opened this issue Nov 17, 2023 · 0 comments
Open

MQ unacknowledged retries are not very multiprocess-intelligent #344

natefoo opened this issue Nov 17, 2023 · 0 comments

Comments

@natefoo
Copy link
Member

natefoo commented Nov 17, 2023

If enabled with amqp_acknowledge, the client will request acknowledgement of messages it has sent by requesting a return message on the corresponding _ack exchange. If it does not receive that ack within amqp_ack_republish_time, it will resend the message.

On the other end, a receipt is kept of messages that have been received and acted upon, so that if acknowledgements were sent but not received, retransmission does not result in duplication of work.

If you have multiple handlers serving the same Pulsar endpoints, each one of these handlers will start an ack manager that will review any unacknowledged messages, retransmit any over amqp_ack_republish_time, and then go to sleep for 15 seconds before doing it again. There is no locking between processes, only internally, so multiple acknowledgement managers could retransmit the same message. This is probably harmless, but not ideal.

Additionally, the acknowledgement persistence_directory needs to be on a shared filesystem if handlers are located on multiple hosts.

Ideally for any unique set of runner + manager, handlers would elect one of themselves as the acknowledgement manager.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant