On 11/04/2013 03:19, Rajiv Mordani wrote:
>
> On 4/10/13 6:25 PM, Mark Thomas wrote:
>>
>> The problem I have is that WebSocket requires some writes to be
>> blocking and some non-blocking. With the above limitation I don't see
>> a way to do this. If a container thread does something that triggers
>> a blocking write that can't complete immediately I need a second
>> container thread to call onWritePossible() to enable the first thread
>> to continue.
>
> Mark I do not understand the use case fully. If a write is blocking
> then why would you invoke the onWritePossible? Also how do you plan
> to do this using Servlet 3.1 API? If you start using non-blocking IO
> then you cannot use the traditional blocking write.
>
> - Rajiv
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).
Mark