RFR JDK-8087113: Websocket API and implementation

[Chris Hegarty]

Simone,

On 5 Apr 2016, at 20:25, Simone Bordet <simone.bordet at gmail.com> wrote:

> Hi,
> 
> On Mon, Apr 4, 2016 at 5:35 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>>>> On 3 Apr 2016, at 18:43, Simone Bordet <simone.bordet at gmail.com> wrote:
>>>> Threading.
>>>> ---
>>>> WebSocket.sendXXX() calls
>>>> MessagePublisher.send(), which dispatches a to
>>>> MessagePublisher.react(), which calls
>>>> MessageSender.onNext(), which dispatches to
>>>> MessageSender.react(), which calls
>>>> MessageSender.send(), which calls
>>>> Writer.onNext(), which dispatches to
>>>> Writer.write(), which finally writes the bytes to the network.
>>>> 
>>>> There are 3 (!) dispatches to
>> 
>> 
>> POSSIBLY
>> 
>>>> different threads for a WebSocket send().
> 
> "Possibly" as in "almost all the times".
> 
> If the client is idle, the chance that the job dispatched will remain
> queued until the thread that dispatched it goes back to the thread
> pool are *very* small, so we get 3 dispatches almost all the times.

I need to get back into the code, but are you counting the calling thread,
the one invoking sendXXX(), as dispatch 1? We always need this to
allow the caller NOT block right.

Are you specifically saying that TEXT decoding, masking of the 
payload, and sending should all happen in a single task?
What the implementation does is to split these into separate tasks,
so that they can be performed in parallel for large messages. Are
you suggesting that this is not really worth it? At least for small
messages, or maybe not at all.  It would simplify the implementation
somewhat.

> If the client is busy, it is possibly worse.
> A single send() will be queued at the end of the thread pool queue.
> Meanwhile, other tasks are dequeued and queued to the thread pool
> queue, until our task gets finally dequeued.
> There, it is queued again at the end of the queue.
> Rinse & repeat 3 times.
> A single send() that could have been performed immediately is now
> walking the thread pool queue 3 times.
> 
> Sure, there is a slim chance that the same thread that dispatched the
> task is the thread that actually dequeues the task to run it, but by
> the time that thread dequeues the task in a busy client the cores will
> have processed a bazillion other tasks so that their caches will not
> even remember that task, causing increased latency.
> 
> I would hope that this issue will be reconsidered and implemented with
> zero dispatches.
> OpenJDK teams can access directly qualified people working on
> java.util.concurrency to discuss the possible approaches, right ?

Yes.

-Chris.

> Thanks !
> 
> -- 
> Simone Bordet
> http://bordet.blogspot.com
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz