hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitry Potapov <potapo...@gmail.com>
Subject Re: Three different HttpContext in HttpAsyncService
Date Mon, 06 Oct 2014 11:18:25 GMT
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
> > 
> > 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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message