cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Async http client experiments....
Date Wed, 05 Sep 2012 14:49:59 GMT

On Sep 5, 2012, at 9:26 AM, Oleg Kalnichevski <olegk@apache.org> wrote:
> HC connection pools distinguish between route info and connection state.
> Routes are immutable and are well known in advance. A route in its basic
> form is a scheme/host/port combo. At connection creation time only the
> route matters as all HTTP connections start out their life cycle as
> state-less per HTTP specification. In real life settings, however, HTTP
> connections may acquire certain state during their life-cycle, for
> instance, by serving a resource protected with a connection based auth
> scheme such as NTLM. So, the object that represents a state of a
> connection may need to be associated with the connection after it has
> already been created. SSL is similar. An HTTP connection can be created
> as plain and later get upgraded to TLS/SSL. If the target server
> requires the client to authenticate itself with a certificate, the
> connection becomes state-full after successful authentication only.   
> 
> Once a connection becomes state-full it can only be leased if requested
> with the same combination of route info and state. I believe this is the
> reason why you are getting a new SSL connection for each new HTTPS
> request. I guess the state object used in the lease request is not equal
> to that associated with the pool entry.

Well, I was actually getting the opposite.   Since the "state" object wasn't stored anywhere,
I was getting a single connection for all the SSL requests to a service/host and thus was
ending up having the wrong credentials after the first connection.    For now, I forced a
dummy state object on there to force a new connection per request to avoid the security issue
of wrong credentials.   Once I figure all the state things out, this should fix itself.

> If in your case SSL context details are effectively a given, you should
> make then a part of the route info instead of the state. HC connection
> pools are designed to be able to use any arbitrary immutable class as a
> route info.

OK.  Subclass AbstractNIOConnPool instead of using BasicNIOConnPool.

>> 2) Lots of issues trying to associate the request with the connection at connection
creation time.   I needed information from the request in order to setup the SSL stuff.  However,
I had a LOT of issues trying to accomplish that.   The only thing the ConnectionFactory gets
it the IOSession.  All that has in it is the HttpHost.  The HttpHost is final.   The connect
occurs on a different thread so thread locals won't work.   Also note that all the fields
in SSLIOSession are final and private.  Thus, I also couldn't find a way to delay the SSL
setup stuff till later.  Thus, I had to get the request/connection stuff associated up front.
 I ended up using a IdentityHashMap to associate the HttpHost with the request stuff, but
it seemed very hacky.
>> 
>> Not really sure what the right solution would be.   My initial thought was to make
HttpHost non-final so that I could subclass it with an CXFHttpHost or SSLHttpHost or something
that would contain extra methods that I could call.   Alternatively, add a "properties" map
to HttpHost or similar that I could store additional stuff.   Another option would be to have
the IOSession passed to the factory also contain the "state" (if specified)  as a property
that could be queried.  
>> 
> 
> Just ditch HttpHost. You obviously need a richer class to represent
> connection routes. HttpClient has HttpRoute class for that matter. You
> probably should be using a custom class that also includes HTTP proxy
> and SSL context bits specific to CXF.
> 
> Does this help you in any way?

Yep.   Just feels like I have to subclass/override a lot of behavior from HC instead of "using"
it.   If HttpHost wasn't final, it would be so much more useful.   Is there a particular reason
why it has to be final?

Still not sure about the Proxy stuff at all, but that's likely because I don't know much about
Proxies at all.  I'll likely need to look more into what proxy stuff does on the wire.


-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com


Mime
View raw message