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: > > Hello everyone, > > > > Until today I was under a misapprehension that there is single HttpContext > > travels across handlers and callbacks during request processing. Today I've > > discovered that during single request processing HttpAsyncService can > > operate > > with three different HttpContext: > > 1. BasicHttpContext created in .requestReceived(). This context will have > > HTTP_RESPONSE and HTTP_CONNECTION attributes. > > 2. BasicHttpContext created in .exception(). In case of HttpException > > thrown > > from HttpAsyncRequestHandler.handle() function, this context will be > > empty. > > 3. SessionHttpContext created by NHttpConnectionBase.setSession(). This > > context will be passed to ConnectionReuseStrategy.keepAlive() and will > > have > > HTTP_CONNECTION set, but no HTTP_RESPONSE. > > > > Is this contexts separation is intentional and there are some reasons to > > have > > them separated and containing different set off attributes? > > As for me, it seems reasonable to use NHttpConnection.getContext() in all > > three > > cases listed above. Which pitfalls I'm missing here? > > > > Dmitry > > HTTP sessions can span across multiple connections (this is especially > applicable to the client side where it is pretty common) and the same > persistent connection can be used by multiple logical sessions. So, > HttpCore attempts to maintain a clear distinction between connection > contexts and execution contexts, which are often not the same. OK, I got it. The separation between connection context and request context is not clear to me.
> > 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? 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. > > Point (3) sounds like a bug to me. However, it does not seem to be the > case in the latest revisions of trunk and 4.3.x. If I missed something > please do let me know or, better yet, submit a pull request ;-) This is my bug, sorry. I have worked on dirty trunk after trying to fix (2). > > 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]
