jsr340-experts@servlet-spec.java.net

[jsr340-experts] Re: NIO specification clarification

From: Rajiv Mordani <rajiv.mordani_at_oracle.com>
Date: Thu, 11 Apr 2013 00:19:25 -0700

On 4/10/13 6:25 PM, Mark Thomas wrote:
> On 10/04/2013 18:45, Rajiv Mordani wrote:
>>
>> On 4/10/13 6:50 AM, Rémy Maucherat wrote:
>>> On 04/10/2013 03:50 AM, Mark Thomas wrote:
>>>> I've been looking in detail at the NIO changes and have a couple of
>>>> questions. In section 3.7 we have the following:
>>>>
>>>> The Servlet container must access methods in ReadListener in a thread
>>>> safe manner.
>>>>
>>>> There is equivalent text in section 5.3:
>>>>
>>>> The Servlet container must access methods in WriteListener in a
>>>> thread safe manner.
>>>>
>>>>
>>>> I recall some discussions around this area but not this exact
>>>> language. It is not clear to me how one accesses a method in a thread
>>>> safe manner since thread safety is a property of the method
>>>> implementation not of how it is accessed. A search of the archives
>>>> did not provide any illumination either. So, I have two questions.
>>>>
>>>> Q1. What exactly does the above mean?
>>>>
>>>> Q2. Why was this requirement added?
>>> I think this is supposed to mean that there should be only one
>>> container thread doing actions related to a particular request
>>> processing, such as calling the read/write listeners, invoking async
>>> dispatches, etc. If that is correct, the statement could be more
>>> precise.
>>
>> Yes that is correct. Am happy to add a clarification to this but just so
>> everyone knows we have submitted for final approval ballot so we need to
>> either decide today what we want to replace this with or wait for an MR
>> to clarify this.
>
> OK. That covers that what it is meant to mean but doesn't address the
> why.
>
> The issue that caused me to look at this is Tomcat's WebSocket
> implementation. I am trying to make it container neutral and just use
> the Servlet 3.1 API.
>
> 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

>
> If there is a good reason for this limitation then I'll have to give
> up on my container neutral implementation and use container specific
> APIs to control the blocking as that will enable me to implement it
> with the single container thread limitation.
>
> Mark