-
Notifications
You must be signed in to change notification settings - Fork 83
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
Worker "grabs" jobs for queuing locally, taking them from other gearman workers #14
Comments
It's really a bug. Thx! -_-!
This package was designed for giving users good experience. Let the GRAB limitation replace EXEC limitation may be a good way to try. Again, thank you for your help! |
I'm still able to reproduce this using the steps above |
Before this, a worker will grab more jobs than its capability. It's still an issue. Reopened! |
@mikespook Have you put any more thought into this issue? I can get it work if you just have one job per worker at a time. So you go from:
to
This way there is one job running per connection to the server. It simplifies a lot of stuff. Let me know what you think about this change and I can submit a pull request. |
I think I am facing this issue, I have a job that launches another job and waits for it to complete.
the worker still accepts the second job and queues it. Since the first job depends on the second to complete, it gets stuck. Would it make sense for the worker launched with New(1) to accept only one job and wait for it to finish before accepting another one? Is there any workaround to this? |
I'm working on it. Hope it could be done before Xmas. PS: Sorry for delay. A contract job has made me crazy. |
"Executing Block" to "Grabbing block" Known issue: ALL_YOURS is not supported |
@mikespook How can we have multiple workers pick up the job and where do we need to update the Ip's of multple workers |
@mikespook |
This is a problem if you want to limit the amount of "functions" run concurrently, ie. if you want to run one job at a time.
What happens is the worker continuously accepts jobs from the server while only running running n at time (
worker.New(n)
where n not equal to 0). The major problem with this is those jobs cannot be run by other workers, thus losing a lot of the power of gearman. Also pinging the server for job status will says all the locally queued jobs are running, when only n are (see example below).Given this limitation, this code should not be used. I was unable to fix this in an elegant way as the nature of the implementation has a bunch of stuff going on concurrently and was unable to put in a nice fix to limit things.
I recommend simplifying everything so one worker has one connection to each gearman server and can only do one job at a time. If you need to run multiple functions at a time then create multiple workers
How to reproduce
(echo status ; sleep 0.1) | nc 127.0.0.1 4730
on the console to see what is queued on the gearman server. You should seeThis means 100 test jobs queued, 0 running, and 0 workers connected who can do this job.
(echo status ; sleep 0.1) | nc 127.0.0.1 4730
in another terminal. You should see something likeThis means 97 jobs are still waiting to complete, 19 are running and there is 1 worker working.
The text was updated successfully, but these errors were encountered: