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 worker auto-respawning with max tries #2

Open
rauchg opened this issue Jan 29, 2012 · 6 comments
Open

Add worker auto-respawning with max tries #2

rauchg opened this issue Jan 29, 2012 · 6 comments

Comments

@rauchg
Copy link
Contributor

rauchg commented Jan 29, 2012

  • Option to ensure that if a worker dies it tries to respawn immediately ?
  • Option to ensure number of active workers always stays at numWorkers or above ?
  • Option to ensure that there's always at least one worker alive and otherwise respawn ?
  • When respawning, if worker fails to listen within certain timeout, retry ?
  • Have a retry threshold to avoid overload ?
  • When respawning, if worker dies shortly after listening, consider it an unsuccessful respawn and try ? This means it would still be captured by the retry threshold and you can't get into an endless cycle of considering the worker spawned, then dying shortly after listening, then triggering reload, ad infinitum.
@malkomalko
Copy link

Hi Guillermo,

First of all... really loving up. Right now when a worker dies there is no respawn.. is that correct? Is there any current strategy at ensuring workers stay alive? Maybe listen for a worker failure and send a kill -s SIGUSR2 to the master pid?

@rauchg
Copy link
Contributor Author

rauchg commented Feb 15, 2012

Right now I have nothing for worker reloading I believe. We can start with the simplest implementation, but it quickly can get out of control if you don't cover many of the things I mention in this ticket. eg: crazy recursive/cyclic reloads that bring the server down because of faulty code.

@rauchg
Copy link
Contributor Author

rauchg commented Feb 15, 2012

At the same time, maybe that problem needs to be solved at a different layer of abstraction.

@arohter
Copy link

arohter commented Apr 18, 2012

See my comments in #21

@kevireilly
Copy link

It seems this has been integrated and documented, but has not yet been translated to the npm repository. Just a heads up.

@cmawhorter
Copy link

I think merging #60 will close this out.

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

No branches or pull requests

5 participants