On Mon, 2014-10-06 at 17:22 +0400, Dmitry Potapov wrote: > > On 06 окт. 2014 г., at 16:36, Oleg Kalnichevski <[email protected]> wrote: > > > >> On Mon, 2014-10-06 at 15:18 +0400, Dmitry Potapov wrote: > >>> On Mon, Oct 06, 2014 at 11:19:12AM +0200, Oleg Kalnichevski wrote: > >>> On Mon, 2014-10-06 at 11:35 +0400, Dmitry Potapov wrote: > > > > ... > > > >>> > >>> Point (2) is really a fringe case intended to ensure there is a context > >>> of _some_ sort even in case an exception is caught before the session is > >>> fully set up. > >> So, here the focal point of my efforts. In case of complete request > >> consumption > >> setIncoming will be called with null argument and request context will be > >> moved > >> to pipeline entry. Right before request handling pipeline entry will be > >> polled > >> from queue, so, no global references to request context will left. So, > >> there is > >> no way how HttpAsyncService.handleException() or > >> ConnectionReuseStrategy.keepAlive() can receive actual request context. > >> The question is: how to extend request context lifetime? > > > > The request and the context associated with it are still present in the > > request pipeline, aren't they? If there is no incoming request and the > > pipeline contains one entry only it should be safe to assume that entry > > be the actual request. > > > >> For now the only solution I see is to store context somewhere else, like > >> State, > >> for instance. But this doesn't seems to be a good solution. Will think on > >> this > >> a bit more. > >> Please, let me know if you have any good ideas where context can be stored. > >> > > > > Why not taking it from the pipeline? > Pipeline queue will be empty in .exception() function, because pipeline entry > will be polled from queue right before calling handler.handle(...)
Dmitry Could you please put together a test case demonstrating such execution path? Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
