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

Discussion: should the master spawn a new worker if an exception kills one? #21

Open
brianloveswords opened this issue Apr 16, 2012 · 2 comments

Comments

@brianloveswords
Copy link
Contributor

Is it/should it be one of the design goals of up to add a new worker to the pool if one dies unexpectedly?

A contrived example, but a server like the following can only survive N requests, where N is the initial number of spawned workers.

// server.js
function hdlr (request, response) {
  response.end(''+Math.random());
  process.nextTick(function () { crash(); })
}
module.exports = require('http').createServer(hdlr);

I think it'd be great if up could ensure that it never gets to a point where there are zero active workers. I've been experimenting with using up in a semi-production environment and I've been burnt by this before, but I wanted to make sure this wasn't a WONTFIX type of issue before putting any time into patching it.

@arohter
Copy link

arohter commented Apr 18, 2012

I'd definitely love support for dead worker respawning.

For me, a simple pair of config options would work, as per #2 discussion:

  1. max respawn rate - don't respawn more frequently than once per XX sec
  • prevent auto-respawning storms from overloading the system
  1. worker listen timeout - if a spawned worker fails to listen in XX sec, kill worker
  • ensure newly spawned workers are truly "alive"

Both of those are really just primitive safety measures, and could just be based on a single interval config value.

Not looking for anything sophisticated - just a simple and reliable way to occasionally restart dead processes in an otherwise-healthy system - more permanent/disastrous problems can be detected an dealt with elsewhere.

@brianloveswords
Copy link
Contributor Author

Ahh I should have read more closely, I didn't realize issue #2 was basically talking about this. I suppose I can take that to mean that it's a goal waiting for an implementation?

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

2 participants