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.
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