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

Order of operations in message acknowledgement / consumer failure #349

Open
elazar opened this issue Nov 27, 2017 · 1 comment
Open

Order of operations in message acknowledgement / consumer failure #349

elazar opened this issue Nov 27, 2017 · 1 comment

Comments

@elazar
Copy link
Contributor

elazar commented Nov 27, 2017

In Consumer->invoke(), if the routed callback throws an error or exception, the subsequent message acknowledgement never occurs.

When using FailureSubscriber, the result of this is that the original message both remains in the original queue and is added to the designated failure queue.

Because the original message never leaves the original queue, the consumer continues attempting to process it, likely encountering the same issue that caused the original error or exception to be thrown, and causing duplicate messages to be added to the failure queue in the process. This continues ad nauseam, filling up the failed queue.

This doesn't seem like it should be intended behavior. If anything, I would think that message acknowledgement should happen first. That way, the message will still end up in the designated failure queue if FailureSubscriber is in use, but the consumer won't continue trying to process it.

Thoughts?

@sagikazarmark
Copy link
Contributor

Sounds reasonable, but to be honest, I'm not a huge fan of the current event dispatching solution. Massive rewrites are happening, this might be part of it as well. If not, we can get back to this after that.

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

2 participants