Simone, On 5 Apr 2016, at 20:25, Simone Bordet <simone.bor...@gmail.com> wrote:
> Hi, > > On Mon, Apr 4, 2016 at 5:35 PM, Chris Hegarty <chris.hega...@oracle.com> > wrote: >>>> On 3 Apr 2016, at 18:43, Simone Bordet <simone.bor...@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
