-
Notifications
You must be signed in to change notification settings - Fork 60
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
Messages go into infinite immediate retries in case there are a lot of messages (over 100) with persistent issue while processing. #1259
Comments
In addition we have also noticed that switching PrefechMultiplier to 1 makes immediate retries to work properly |
We also prepared a solution with minimal configuration with which we were able to reproduce the error. |
@bonieckimarcin @bsmykowskiinf Thanks for including a repro project. That will make it much easier to investigate. One question. I see you're using classic queues. Have you tried quorum queues? It would be good to know if it works properly with quorum queues or still fails in the same way. |
I can reproduce the issue, and as I suspected, it only occurs when classic queues are used. The broker provides retry count information for us via the For this reason, and many others, I highly recommend converting to quorum queues as soon as possible! We have a migration guide and a tool to help you do this. Regarding a fix for when running on classic queues, locally tracked information is never going to be as reliable as information provided by the broker, but we could increase the capacity of the collection. It would still be possible to hit this problem if there are enough failing messages in the queue regardless of how large the collection is, but it's clear that the current value of 100 is too low! |
Upgrading to quorum is on our to do list. But looking at size and complexity of our project, it requires a lot of testing and we are not able to do that immediately. We still have to work with classic queues for some time. |
Describe the bug
Description
We have encountered a problem with infinite loop in immediate retries in case there is a lot of messages in queue one next to each other (during tests it was between 100 and 1000), which have persistent issue while processing. After a configured number of immediate retires (2 for proceeded test) all messages go to first delayed retry. Next after configured delay messges are going back to processing. At this moment they undergo infinite immediate retries and never go to delayed retry again.
We have noticed that this problem occurs when LimitMessageProcessingConcurrencyTo is set to more than 1.
Expected behavior
Messages go through immediate, then delayed retries and finally will land in the error queue.
Actual behavior
Messages after first iteration of immediate retries go to first delayed retry. After that they undergo infinite immediate retries.
Versions
Affected package:
Tested with:
Steps to reproduce
Relevant log output
Additional Information
Workarounds
or
The text was updated successfully, but these errors were encountered: