You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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?
The text was updated successfully, but these errors were encountered: