Page MenuHomePhabricator

Support node cluster sticky-session in service-runner
Closed, DeclinedPublic0 Estimated Story Points

Description

In order to use node cluster with socket.io, multiple requests from the same client need to be routed to the same worker.

https://github.com/indutny/sticky-session does this, but integrating this with service-runner's master and worker code isn't straightforward (at least to me).

The setup for sticky session is different than plain ol' node cluster use. For sticky sessions, the master process needs to explicitly call server.listen, and then incoming connection handles can be sent to worker processes. This is how sticky-session works.

Since service-runner supports running multiple services via different service modules, integrating sticky support seems hard. service-runner expects each worker to call server.listen, which won't work for sticky-session.

Is this worth doing? I'd really like to use Kasocki in service-runner, but I'm not sure if fits the service-runner model. If not, I could just bring in a lot of the service-runner ideas and code into a fork or new repo and make it work with sticky-session.

Event Timeline

Hm, we will need to support some kind of ip hash based load balancing (from varnish?) in order to route sessions to the same box anyway. Alternatively we could just manually manage the worker processes without node cluster, and have them each listen on a unique port.

GWicke lowered the priority of this task from Medium to Lowest.Oct 13 2016, 12:01 AM
GWicke edited projects, added Services (watching); removed Services (later).

I would really prefer to avoid messing with sticky sessions & related issues. If we do end up using plain HTTP (ex: Server Sent Events), then there shouldn't be a need for them. See T130651 for that discussion.

We decided to use HTTP + SSE, instead of socket.io. Declining this ticket.