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 Tue, 04 Sep 2012 19:20:33 GMT

On Aug 6, 2012, at 10:43 AM, Oleg Kalnichevski <olegk@apache.org> wrote:
>>>> CXF allows these to be configured on a per-client (and sometimes even
>>>> per- request) basis.    It looks like HC seems to have these on the
>>>> connection factory.
>>> 
>>> It does not have to be this way. Connections can start off as plain and
>>> later get upgraded to TLS/SSL by the protocol handling code. One would
>>> have to tweak the default protocol handler a bit, though, probably by
>>> overriding the HttpAsyncRequestExecutor#requestReady method [2].
>> 
>> Ah.  OK.   I'll take a look there.   I was looking in the various connection 
>> factories and pools.   Haven't looked there yet.   Lots of stuff going on.  
>> :-)
>> 
> 
> I also added a CXF specific connection manager implementation in order
> to enable SSL customization based on request configuration. However,
> before I proceed I would like to understand the requirements a little
> better. Can I assume that once an SSL connection has been fully set up
> using request level config parameters and can be pooled and safely
> reused for subsequent requests to the same service (even by different
> users) or requests may contain different / incompatible SSL
> configuration for the same service?   

They may contain different configurations.  Particular different client certs if using client
certs as the authentication mechanism. 

I found the "state" object to pass into the connection factory and plan on implementing a
new state object that will attempt to handle that by comparing the various values on the HTTPConduit
settings.    However, I *DID* run into a couple problems that, while I was able to work around
them with some hacks, they likely should be fixed in the HTTP stuff.  In particular:

1) The "state" object that is passed into the factory is never saved anywhere.   IMO, if a
new connection is created based on the state, it might be good to record that state (or at
least make that an option) so the state stuff actually works.   I got around this by subclassing
the BasicNIOConnPool to override the BasicNIOConnPool.createEntry method to add a state object
to the entry.   A bit involved.

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.  

Anyway, things are definitely in "ok" shape right now.   Definitely making some significant
progress.  Slowly but surely.

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


Mime
View raw message