Example of second way of delegating connections to cluster workers

[basickarl]

https://nodejs.org/api/cluster.html#cluster_how_it_works states:

The second approach is where the master process creates the listen socket and sends it to interested workers. The workers then accept incoming connections directly.

I've read the documentation but haven't really figured out how to put it together. I've come up with the following code (I don't know how to pass the socket object):

'use strict';

const cluster = require('cluster');
const net = require('net');
const http = require('http');

if (cluster.isMaster) {
    const numCPUs = require('os').cpus().length;
    for (var i = 0; i < numCPUs; i++) {
        cluster.fork();
    }

    const socket = new net.Socket(); // Socket to send to the worker.
    socket.connect(3000);
} else {
    http.Server((req, res) => {
        res.writeHead(200);
        res.end('hello world\n');
    }).listen(socket);
}

Would be nice to see this in the documentation later^^.

[bnoordhuis]

The cluster module is for servers, i.e., listen sockets. In your example, you could send the client socket to a worker with cluster.fork().send('message', socket) but honestly, there isn't much point - the worker could just create the connection itself and it would be faster to boot.

[cjihrig]

As a side note, I don't think we should encourage people to do a lot of passing of sockets between processes. My experience has been that it's prone to race conditions and data loss.

[basickarl]

@cjihrig Ah yes, would explain the warning in the documentation (says the same). However I'd like to know how to do this for educational purposes only (I currently run clustering the first way).

[cjihrig]

Actually, after reading the documentation again, it looks like that part is just referring to the scheduling policy. It would probably be more clear to link to the scheduling policy from the How It Works section.

[Trott]

This issue has been inactive for sufficiently long that it seems like perhaps it should be closed. Feel free to re-open (or leave a comment requesting that it be re-opened) if you disagree. I'm just tidying up and not acting on a super-strong opinion or anything like that.

[huenchao]

mark

[briantbutton]

Can we re-open this issue? At a minimum, we should fix the documentation.

It says, there is a second approach to scheduling (but throws aspersions that it does not work very well). Then it never mentions it again, shows syntax or even elaborates on the terminology.

I would dearly love to see an intelligent way of parceling out incoming tasks from an https socket. We have giant cumbersome transaction and short time-sensitive transactions. We need to make sure some cores stay free of big transactions to provide good response time on the little ones.

If there is a smarter method, can it please be explained in the documentation? If there is not one, can we rip out those passages entirely? Half-mentioning such a method, then throwing shade on it seems . . . uh not good.

I presume this limbo state has existed for more than six years now.