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