-
Notifications
You must be signed in to change notification settings - Fork 405
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
feat(worker): better handling of concurrency when fetching jobs #2242
Conversation
## [4.12.7](v4.12.6...v4.12.7) (2023-10-29) ### Performance Improvements * **redis-connection:** check redis version greater or equal than v6 only once ([#2252](#2252)) ([a09b15a](a09b15a))
…askforcesh/bullmq into feat/better-worker-concurrency
|
||
// Remove marker from active list. | ||
await client.lrem(this.keys.active, 1, jobId); | ||
if (this.blockUntil > 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
but could it be the case that when doing this logic, one delayed job with a lower delay value was added, so if we break here, blockUntil will have a higher value than expected, on the other hand if we continue, we will call moveToActive and get the most updated value if this case happens
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, if a delayed job with lower delay was added, then when calling BRPOPLPUSH we will move the new marker right? and update the timeout accordingly. We must block sometimes, otherwise we will enter in an endless loop calling moveToActive.
# [4.14.0](v4.13.3...v4.14.0) (2023-11-18) ### Features * **worker:** better handling of concurrency when fetching jobs ([#2242](#2242)) ([d2e2035](d2e2035))
Handles this issue: #2157