On 4/11/13 5:15 PM, Mark Thomas wrote:
> 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).
Is this from JSR 356 or in general that is the case?
>
> 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.
Ok so you are not truly using blocking and non-blocking together but
more so emulating the block. That should be fine as far as the servlet
spec goes.
>
> 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).
I wish we had some of these use cases come out earlier. Let's try to
address some of the concerns to around building the implementation in a
container neutral manner in a subsequent release.
- Rajiv
>
> Mark
>