On Sep 5, 2012, at 9:26 AM, Oleg Kalnichevski <[email protected]> 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 [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
