Different HttpContexts with 4.2.x

["Asankha C. Perera" <as...@apache.org>]

Hi All

During our migration to HC 4.2.x we encounter some issues related to the 
different HttpContexts available - one which is usually a 
BasicHttpContext and the other based on the IO session. In our code for 
example if we encounter any exceptions or a timeout etc, we need to 
report that as a failure against objects originally available to the 
local HttpContext, but also with connection related information 
extracted from the connection / session. i.e. we need information from 
both HttpContexts

I was wondering if there are some guidelines on how one should use each 
of these, or make attributes placed into one available to the other 
etc.. If this area could be simplified somehow for the 4.3.x releases, I 
think that would be great.

regards
asankha

-- 
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com




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

Re: Different HttpContexts with 4.2.x

["Asankha C. Perera" <as...@apache.org>]

Hi Oleg
> I/O session level context is specific to one particular session and also
> limited in its life time to that of the session. HTTP exchanges can span
> across multiple connections (sessions). This is especially the case of
> the client side. That is the reason for using another context at the
> protocol handler level.
Thanks for this insight.. I didn't notice the case for the local context
> Generally you should always be able to get the underlying connection
> (session) from the local context and get hold of the connection level
> attributes.
This is slightly different for new connections which fail, as there is 
no connection, I think this was the cause of the initial pain, but we 
are now trying to clean things up and maybe find out a better way to 
keep track of things
> If you have ideas how to simplify the API let's discuss and
> work on them.
Sure, I'll get back if I find any way to possibly improve things

thanks and regards
asankha


-- 
Asankha C. Perera
AdroitLogic, http://adroitlogic.org

http://esbmagic.blogspot.com




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

Re: Different HttpContexts with 4.2.x

[Oleg Kalnichevski <ol...@apache.org>]

On Wed, 2013-02-27 at 17:55 +0530, Asankha C. Perera wrote:
> Hi All
> 
> During our migration to HC 4.2.x we encounter some issues related to the 
> different HttpContexts available - one which is usually a 
> BasicHttpContext and the other based on the IO session. In our code for 
> example if we encounter any exceptions or a timeout etc, we need to 
> report that as a failure against objects originally available to the 
> local HttpContext, but also with connection related information 
> extracted from the connection / session. i.e. we need information from 
> both HttpContexts
> 
> I was wondering if there are some guidelines on how one should use each 
> of these, or make attributes placed into one available to the other 
> etc.. If this area could be simplified somehow for the 4.3.x releases, I 
> think that would be great.
> 
> regards
> asankha
> 

Asankha

I/O session level context is specific to one particular session and also
limited in its life time to that of the session. HTTP exchanges can span
across multiple connections (sessions). This is especially the case of
the client side. That is the reason for using another context at the
protocol handler level.

Generally you should always be able to get the underlying connection
(session) from the local context and get hold of the connection level
attributes. If you have ideas how to simplify the API let's discuss and
work on them.

Cheers

Oleg  


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