Concurrent Connection/Request Handling

[benjchristensen]

A server needs to receive connections (TCP etc) and requests (HTTP etc) concurrently.

For example, on a 32-core machine where each core can be receiving IO connections and requests, each core should be able to process independently of each other.

This means we can not represent a server handler as a Publisher<Connection> or Publisher<Request> since Publisher can not invoke onNext concurrently.

If Publisher was used for this it would result in all CPU cores serializing through the single Publisher.

Thus a server handler must just be a function call that is invoked concurrently whenever a connection or request is received.

[smaldini]

Yeah the oNext argument is somehow interesting, one can argue that serializing the publishers in a non blocking pipeline could leave you manage how many in-flight/concurrent connections you can accept at most. But a Function<> would suit better probably 👍

[rstoyanchev]

Agreed.

This appears to be a duplicate of #7.

[NiteshKant]

Closing this as we seem to agree that a server must not be represented as a Publisher