On 12/04/2013 04:37, Rajiv Mordani wrote:
>
> 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?
This is from JSR 356. It is not from RFC6455.
>>
>> 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.
Exactly.
> That should be fine as far as the servlet spec goes.
It depends on exactly what 3.7 / 5.3 intend. See my more detailed reply
to Remy. There is a form of clarification that would enable this to be
implemented in a container neutral manner.
>>
>> 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.
Me too. Generally I wish there was a much, much longer period of time
for containers to implement the draft final specification and for users
to work with it to iron out any wrinkles before the specification is
made final.
> Let's try to address some of the concerns to around building the
> implementation in a container neutral manner in a subsequent release.
+1. It might be that all is required is a clarification of what is meant
by 3.7 / 5.3.
Mark