I do this with the npmjs.org site using the cluster-master module.

https://npmjs.org/package/cluster-master

I only have to restart the main process if there's a change to the
main server.js file.  Otherwise, I log into the repl, and I can
restart workers one by one, resize the cluster, etc.

Getting all the edge cases handled properly is very app-specific, and
in multi-machine setups, it will be completely extraneous.

So, unlike Ben, I would reject a pull request flat-out for this
feature, unless someone could present a *very* compelling case for why
everyone ought to have the same logic in all their apps.  I don't
believe that this belongs in core.


On Thu, Jun 6, 2013 at 9:41 PM, Evan <[email protected]> wrote:
> I approached this problem a little differently, and have a semi-decent
> solution in actionHero today:
> https://github.com/evantahler/actionHero/blob/master/bin/include/startCluster.js
>
> If the master process is simple enough, you can probably get away with
> rarely reloading it.  Mine only handles the spawning of children and basic
> unix signaling.  Parent and Child don't need to be running the same code, so
> your *real* application code is executed by the children.  When it's time to
> upgrade the code for your application, you roll off (kill one, start a new
> one, repeat) the children until you have a newly spawned collection.
>
> Regarding websockets, one of the main reasons I moved from socket.io to Faye
> is that it supports clients reconnected to another server (with a redis
> backend).  This way, clients will reconnect to a new cluster member as they
> roll over (albiet with some period of disconnect).
>
> On Thursday, June 6, 2013 3:49:59 PM UTC-7, ryandesign wrote:
>>
>>
>> On Jun 6, 2013, at 05:22, Ben Noordhuis wrote:
>>
>> > Secondly, I'm not sure how many people will actually use it.  I assume
>> > most people have multi-machine setups where they simply take machines
>> > out of the load balancer one at a time and upgrade at their leisure.
>>
>> Having not put node into production yet, the procedure you describe sounds
>> far from "simple"; it sounds like an involved multi-step process with many
>> opportunities for human error. Wouldn't automating it in some
>> officially-sanctioned way be good for everyone?
>>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to