RFR JDK-8087113: Websocket API and implementation

[Chris Hegarty]

On 6 Apr 2016, at 09:37, Simone Bordet <simone.bordet at gmail.com> wrote:

> Hi,
> 
> On Tue, Apr 5, 2016 at 11:06 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>> Let's suppose we have a ByteBuffer to send. This ByteBuffer contains 1 MB of
>> data, the socket send buffer is 16 KB, the network is not particularly fast.
>> Suppose then the first pass fills the full buffer's 16Kb completely. So
>> WebSocket has 1,048,576 - 16,384 bytes left to write, but the buffer is still
>> full.
>> 
>> What should I do next in order to be nonblocking within this invocation?
> 
> You write what you can, store in some data structure the buffer,
> register for write interest in NIO, and then return the CF.
> When NIO calls you back telling it's write ready, you write some more.
> Rinse & repeat until you have written everything, at which point you
> notify the CF.

Got it. That could be reasonable.

I note that Pavel used a permits size greater than 1, but the API has a 
single-outstanding-write policy ( ISE is thrown if sendXXX is called before
the previous message was sent ). Maybe this is where some of the confusion 
/ complexity around the implementation comes from. What you are suggesting
sounds very reasonable for a single-outstanding-write, where you know you 
can always attempt to write to the socket.   If this policy was to be revisited
then it is somewhat less attractive, it is more opportunistic.  I have no reason
to think that this API choice would be revisited, just that it may explain where
we are today.

>> Sorry Simone, which thread pool are you talking about? In case you meant
>> SignalHandler, it doesn't have a queue. It's built on "opportunistic" repeating
>> of the same task over and over again.
> 
> I mean the Executor you get from HttpClient.
> Executors have a queue.
> 
>> May I ask in what thread you think WebSocket.Listener's invocations should be
>> dispatched?
> 
> IMHO they should not be dispatched. You just call WebSocket.Listener
> methods from the thread that performed the read.
> 
>> On another topic. Let's consider many different WebSocket connections have been
>> established simultaneously. But the nature of these connection such that they
>> are all different in their speed. How would you suggest one should organize and
>> scale this?
> 
> You have to define what you mean by "organize and scale", and what is
> the real problem you are trying to solve.
> I would not start worrying about this until the implementation is
> simple and efficient.

-Chris.