On 6 Apr 2016, at 09:37, Simone Bordet <simone.bor...@gmail.com> wrote:
> 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. 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.
