cluster:RR - Added public API pausing/unpausing a worker

[Yemanu]

cluster:RR - Added public API pausing/unpausing a worker

We have the following two use-cases:

1. Run offline GC, we have a script which coordinates offline GC using pause and unpause API. Basically, the master process is able not to distribute new requests to a paused worker by calling cluster.pause(worker). The paused worker can force full GC after draining all pending requests in its flight. Once it is done the worker can continue to server new request after the master cluster unpauses it by calling cluster.unpause(worker).

2. Respawn a worker after serving X requests. The master cluster should not distribute requests to the new worker until it prime-cache which may take few seconds. We need to pause it while prime caching the worker.

This enabled us to reduce long tail latency.

There has been discussion about this on how best to this feature (#7695)

[cjihrig]

I'm not really a fan of this approach. I'd prefer allowing the user to define the scheduling policy, which I believe was discussed in #7695.

[Yemanu]

Colin - Thanks for your quick response.

I think in the previous discussion we try to avoid exposing RR handler to the public API. I was thinking using explicit pause/unpause API make it more useful for various uses cases.

How can we user defined scheduling policy be used without exposing RR handler to the public API?

[Yemanu]

@cjihrig FYI: we (at Yahoo) also tried different approach https://github.com/bengl/toor using socket, but this doesn't work if the keepAlive option is on.

[Trott]

/cc @bengl

[bengl]

@Yemanu I opened an issue on bengl/toor . Can you please add further detail there about the keep-alive issue?

[Yemanu]

@bengl one of the issues with toor that is http-shutdown closes all ideal keepAlive connection, so it causes additional connection overhead.

[Yemanu]

Toor is also using the shimer module, and we need to fully understand the implication of using shimer like that other than debugging :)

[jasnell]

Updates on this one?

[bnoordhuis]

This has been superseded by #11546. I'll close it out.