Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Message-ID: <1412603382.1196.2.camel@ubuntu>
Subject: Re: Three different HttpContext in HttpAsyncService
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpComponents Project <dev@hc.apache.org>
Date: Mon, 06 Oct 2014 15:49:42 +0200
In-Reply-To: <5D5759B5-3A6E-4A7C-A23A-3CF963C885E2@gmail.com>
References: <20141006073500.GA2418@localhost.yandex.net>
	 <1412587152.27735.17.camel@ubuntu>
	 <20141006111825.GA2653@localhost.yandex.net>
	 <1412598983.31683.4.camel@ubuntu>
	 <5D5759B5-3A6E-4A7C-A23A-3CF963C885E2@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit

On Mon, 2014-10-06 at 17:22 +0400, Dmitry Potapov wrote:
> > On 06 окт. 2014 г., at 16:36, Oleg Kalnichevski <olegk@apache.org> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org