Hi, 2016-10-27 13:53 GMT+03:00 Rémy Maucherat <r...@apache.org>: > > 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.
Yes I agree. I'll post a question in the EG mailing list for clarification. Regards, Violeta > Rémy
