Prevent too many ProcessBacklog() from being scheduled #1574
Conversation
devbv
changed the title
|
@mgravell I am also seeing these errors in my logs. They are a semi related to the issue solved with #1585 in that in these timeout scenarios seems to cascade and build upon each other, and the library struggles to recover. I would also be interested in seeing your opinion on getting this change in as well |
|
|
|
Merging main in here for build check changes |
- make the backlog processor async - check for work *before* trying to get the lock
|
This is a great find, and could explain a lot, but I'm not sure that the approach is the best way of solving it - I'm playing with an alternative strategy in #1612 - but: even if I merge that, I'll still give credit for the research here; much appreciated! |
|
Have merged #1612, but credited in release notes:
|
* alternative implementation along the lines of #1574: - make the backlog processor async - check for work *before* trying to get the lock * release notes
4 participants
This PR prevents the situation that a consumer makes the number of backlog 1->0 infinitely and many producers schedule new ProcessBacklog() after they make the number of backlog 0->1.
The situation could lead a starvation of thread pool and a lot of timeout when we use transaction heavily. (#1572)