Hi, On Tue, Apr 5, 2016 at 11:06 PM, Pavel Rappo <pavel.ra...@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. > 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. -- 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
