2016-10-23 8:22 GMT+02:00 Violeta Georgieva <miles...@gmail.com>: > Hi Remy, > > 2016-10-21 15:11 GMT+03:00 Rémy Maucherat <r...@apache.org>: > > > > 2016-10-21 13:21 GMT+02:00 <violet...@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.
Rémy
