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

Add ability to control the dequeue #421

Merged
merged 9 commits into from
Aug 21, 2020
Merged

Conversation

ananthakumaran
Copy link
Collaborator

@ananthakumaran ananthakumaran commented Jul 11, 2020

Problem

Currently, Exq provides concurrency control per queue per worker node. But if anyone wants to rate limit based on different factors, it's not possible to do unless via middleware. The problem with going via middleware is, the job is already dequeued at that point and the only way to stop further dequeue is via unsubscribe API. The unsubscribe API is async, so we can't control the exact number of jobs dequeued via it.

Proposal

Add the ability to control dequeue operation via a new Behaviour. Exq will provide a default implementation and others can override the default implementation per queue.

POC

I have been working on a POC exq_limit to validate the API. I will try to test it in the coming weeks.

refer #178

@coveralls
Copy link

coveralls commented Jul 11, 2020

Coverage Status

Coverage decreased (-0.09%) to 91.552% when pulling 7058fe5 on dequeue_controller into ade8398 on master.

Currently work_table is being passed to worker server, but it's not
used for any purpose there.
This setups up the ground work for custom concurrency handling by
removing work_table and moves the logic to a separate module.
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

Successfully merging this pull request may close these issues.

2 participants