-
Notifications
You must be signed in to change notification settings - Fork 43
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
Better handling of Pool and job reserve for multiple connections #11
Comments
yeah i see, we should be more smart about it, i think we should stop using Cycling through all connections it's neither the best approach, does threading sounds too crazy? |
Perhaps an approach to try for the reserve method would be to look at the current-waiting counter (from the stats command) for each connection, distributing the reserve commands across connections. The goal being to avoid starving any particular queue for consumers. |
Is there any progress on this issue? I'm rather blocked by this implementation as well. I use on average 3 connections and on average about 1/3 of my jobs don't ever run. Seems like doing a round robin until we find a job in a queue or find no jobs is the right way to go on this one... no? |
Yeah I can think of a several ways to handle this better then we are handling it now. We will tackle this soon although if anyone else wants to take a stab at a pull request, that'd be great. |
I'm aware it's not the best way, there's a workaround by setting up a timeout and eventually it will reserve the job on the right tube:
We'll come up with a better way, but let me know if that workaround works for you |
There is an issue with the pool concept and then with
put
andreserve
. We should change beaneater_test with https://github.com/beanstalkd/beaneater/blob/master/test/beaneater_test.rb#L6 and test with multiple connections.The issue is around how reserving works in this case:
So now we have two jobs on connection one. If we now call
Reserve could randomly pick connection two in which case there are no jobs and it would hang forever. Also other variations of this problem when 2 jobs fall into one connection and one into another and calling reserve will eventually start to hang up even though the other connection still has jobs.
The text was updated successfully, but these errors were encountered: