> 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(...) > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
