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

If you restart beanstalkd, the workers cannot reconnect #2

Closed
mexisme opened this issue Apr 22, 2015 · 4 comments
Closed

If you restart beanstalkd, the workers cannot reconnect #2

mexisme opened this issue Apr 22, 2015 · 4 comments
Labels

Comments

@mexisme
Copy link
Contributor

mexisme commented Apr 22, 2015

You get continual Exception Beaneater::NotConnected -> Could not connect! even when beanstalkd has been correctly restarted.

@mexisme mexisme added the bug label Apr 22, 2015
@mexisme mexisme self-assigned this Apr 22, 2015
@mexisme
Copy link
Contributor Author

mexisme commented Apr 22, 2015

This is actually quite a nasty one.
It may be in Backburner, as that's the system that manages the workers, or it may be in Beaneater, as that tries to pool/cache several connections, and may not be cleaning them up correctly.

@mexisme
Copy link
Contributor Author

mexisme commented Apr 22, 2015

This appears to be a bug in beaneater, and fixed in beanstalkd/beaneater@7fd69f6

(Not cleaning-up pooled connections when the fail)

mexisme added a commit that referenced this issue Apr 22, 2015
@mexisme mexisme closed this as completed Apr 22, 2015
mexisme added a commit that referenced this issue Apr 22, 2015
@mexisme mexisme reopened this Apr 22, 2015
@mexisme
Copy link
Contributor Author

mexisme commented Apr 28, 2015

This seems to be caused by nesquena/backburner#93.
Changing to ::ThreadsOnFork worker fixes the problem.

@mexisme
Copy link
Contributor Author

mexisme commented Sep 15, 2015

FYI: @kuahyeow, @tigerwnz

Backburner collaborator replied to my bug:
nesquena/backburner#93 (comment) :

I see what you're saying with the conflation bit there.
What it should probably do is pass the newly-minted Connection into the work_one_job method (which accepts an optional Connection instance).
The Worker doesn't seem to have/use a @connection instance var.

@mexisme mexisme removed their assignment Sep 15, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant