[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tomcat-dev
Subject:    Re: svn commit: r1765995 - /tomcat/trunk/test/org/apache/catalina/nonblocking/TestNonBlockingAPI.jav
From:       Christopher Schultz <chris () christopherschultz ! net>
Date:       2016-10-31 14:41:53
Message-ID: ac1c65b8-1c69-fae4-72ae-452e850b9e90 () christopherschultz ! net
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]


Violeta,

On 10/27/16 7:28 AM, Violeta Georgieva wrote:
> Hi,
> 
> 2016-10-27 13:53 GMT+03:00 Rémy Maucherat <remm@apache.org>:
>>
>> 2016-10-23 8:22 GMT+02:00 Violeta Georgieva <milesg78@gmail.com>:
>>
>>> Hi Remy,
>>>
>>> 2016-10-21 15:11 GMT+03:00 Rémy Maucherat <remm@apache.org>:
>>>>
>>>> 2016-10-21 13:21 GMT+02:00 <violetagg@apache.org>:
>>>>
>>>>> Author: violetagg
>>>>> Date: Fri Oct 21 11:21:48 2016
>>>>> New Revision: 1765995
>>>>>
>>>>> URL: http://svn.apache.org/viewvc?rev=1765995&view=rev
>>>>> Log:
>>>>> Test case for a delayed registration of WriteListener. Test is
> marked
>>> as
>>>>> @Ignore as it is failing with the current implementation.
>>>>>
>>>>> Although maybe not explicitly disallowed, I would assume you have
> to go
>>>> into non blocking mode right after startAsync in the container thread,
>>> and
>>>> it's not something asynchronous. Any other use probably doesn't make
> much
>>>> sense [even more after an upgrade]. The API lists the APIs that are
>>>> asynchronous and thread safe due to async (basically, AsyncContext)
> and
>>>> this is not one of them.
>>>> So I wouldn't fix this at the moment, especially if it adds
> complexity.
>>>
>>> The Processor for the "Request" that sets the WriteListener is in the
>>> waiting processors list.
>>> Can we introduce additional check if the Processor is in the waiting
>>> processors list then we can execute DISPATCH_EXECUTE.
>>>
>>>
>>> We just had a post on a user list who is trying to do exactly what I was
>> talking about: write operation going on, concurrently set
> setWriteListener.
>> As soon as async is allowed, people will do this, even if inadvertently
>> [the scenario you describe would work however, but there's no way to
>> guarantee it]. I remain convinced that setWriteListener is only allowed in
>> a container thread and not be concurrent with any IO operations, maybe we
>> should seek clarification from the EG though.
> 
> Yes I agree.
> I'll post a question in the EG mailing list for clarification.

If setWriteListener should be restricted to container threads, why would
it be a part of the public API?

-chris


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]