On Thu, 04 May 2017 08:04:39 GMT, Sönke Ludwig wrote:

TCP connections generally can't be safely moved between threads. It might work for some of the back ends by accident, but it can't be relied upon, since they are embedded in a thread-specific data structure.

Since the web socket connection is an incoming one, the only way to control the accepting thread would be to open up one port for each thread. So when a page gets served from the first thread, it might generate code to connect to ws://server:81, while the second one connects to ws://server:82.

Generally, if possible, I'd always favor a multi-process approach instead of a multi-threaded one. So instead of using the distribute option, HTTPServerSettings.reusePort would be used, and then n processes could all listen on the same port. However, that would require to make the application completely state-less and to move any session related data to a separate database/cache, so that may be a performance issue.

If the multiple-port suggestion isn't feasible for some reason, it would be possible to build in a way to move incoming connections between threads before the internal management structures have been built (using an additional pre-connection callback). That would require a bit of work, but could be added to vibe-core/eventcore.

Hi Sönke, thank you for addressing multiple points in your answer.

The dedicated port-per-thread solution is a great idea. However, in my case, where the server instance resides behind a reverse proxy, it makes the proxy configuration dependent on the cores the CPU in target environment does have, which is at least a bit inconvenient to be an ultimate solution. Anyway, I keep this approach in my arsenal.

I do not really see the point in the mentioned multi-process approach. How would this ensure a websocket is bound to the particular TCP handling task's thread. Or have you just meant it to be an add-on comment on the port-per-thread solution? I need to ask as well, why do you favor multi-process over multi-threaded? Having multiple processes sharing the same port seems to me equivalent to having multiple threads within a single process listening on the same port.

I am definitively thankful for the last hint, Sönke. Could you please guide me a bit in the direction where should I hook that callback in? I am prepared to contribute the solution in a PR with a little help of yours then :-)

Thank you very much for your kindness and professionalism.
Ľudovít