On 04/12/2013 02:15 AM, Mark Thomas wrote:
> The WebSocket use case requires switching back and forth between
> blocking and non-blocking writes. (The API defines some writes as
> non-blocking and others as blocking and they can be called in any order).
>
> I am building on top of the Servlet 3.1 HTTP upgrade so I am using the
> ServletOutputStream in non-blocking mode so I can handle the
> non-blocking writes. For the blocking writes I have to make the
> non-blocking write appear to be blocking. For this I am using a Latch
> so the thread that initiates the write isn't released until the write
> completes. If it is a large write the container may need to call
> onWritePossible() several times before the write completes and the
> Latch can count down and the initiating thread released. This only
> works if multiple container threads can access the WriteListener.
>
> Remy's explanation of why we have this restriction makes sense. The
> general case is a lot trickier than the WebSocket case above (and even
> in the WebSocket case I had to be pretty careful with the multiple
> threads). I am heading rapidly towards the conclusion that the
> WebSocket API can't be implemented in a container neutral manner
> (which I think is a real shame).
Not sure I understand why.
With the way it is built, I would say websockets has to use a single big
queue for both its "async" and "blocking" RemoteEndpoint(s), so the
onWritePossible will basically trigger the actual sending of the queue
content.
I don't see why you would need multiple concurrent onWritePossible
notifications to do that [which I have no idea how it could happen
anyway on a single socket]. Did I miss something ?
Rémy