[nodejs] Graceful restart in a preforked node.js

[Peter Griess]

Hi Troy,

That's an excellent idea.

It would require the individual processes themselves to support a graceful shutdown, which would in-turn require support in the http and other network server modules. One way to do this would be to keep the UNIX socket between parent/child open and use it as a control channel (e.g. to request shutdown).

We could do this non-gracefully by simply killing off the children one-by-one and restarting them. This would be far less development work, obviously ;)

Peter

On Tue, May 4, 2010 at 12:37 AM, Troy <tkru...@gmail.com> wrote:

On May 3, 4:12 pm, Peter Griess <p...@std.in> wrote:
>    - The ability to specify a function to return arguments used to spawn new

>    child processes (e.g. to specify a different --debug=NNN port)
>    - The ability to specify a function to dynamically decide whether or not
>    to spawn a new child when one does (e.g. to allow the application to decide
>    at runtime what the fanout should be)
>    - Not requiring a socket path and simply constructing one internally and
>    passing it, say, via an environment variable
>
> Anything else that might be interesting?
>

Would be cool if the parent could restart the children if it received
a USR2 sig without dropping any connections, this is what unicorn does
in ruby land http://unicorn.bogomips.org/ and it is a big life saver
in production deployments.

-- troy


--

You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

--
You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.

[Troy]

The way I understand unicorn works, is the master opens the socket
(which something like nginx proxies too) and each child pulls requests
synchronously, and somehow doing this the request queue us maintained
by the kernel (the requests just stack up on the socket). But the key
point is that the workers go to the master/parent to get work, thus it
seams possible that a child nodejs could do the same asynchronously
and upon receiving a signal would know to stop getting more work,
monitor itself and when existing work is complete, shutdown. In the
meantime, the master/parent has forked new children to handle requests
point forward.

This blog post http://tomayko.com/writings/unicorn-is-unix covers how
it is done and why it's sexy.

-- troy

> > in ruby landhttp://unicorn.bogomips.org/and it is a big life saver

> > in production deployments.
>
> > -- troy
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To post to this group, send email to nod...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/nodejs?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/nodejs?hl=en.