On Tue, 2012-09-04 at 15:03 -0400, Daniel Kulp wrote: > Finally had a chance over the last week or so to re-dig into the async http > stuff. You've probably seen a lot of commits and such related to it. :-) > > Good news: > ALL of the CXF system tests now pass using it instead of the URLConnection > based transport. I'm pretty excited about that as that's a huge milestone. >
Hi Dan I am glad things are shaping up well. > That said, there is still a bit of work todo: > > 1) Proxy support - haven't looked into this at all yet. Hard for me to test > as well as I don't have any sort of proxy setup anywhere. I may need to look > into how to setup a simple proxy to dig into this. > > 2) HTTPs Keep-Alive - right now, with HTTPs, a new connect is created for > every request. With HTTPs, that's really expensive as it needs to do the > handshakes and such for every request. This is next on my TODO to look > at. One issue is that the BasicNIOConnPool really only compares the host > name/port/scheme to determine connection re-use. Not any of the certs or > anything like that. I'll need to implement a "state" object to handle > checking a lot of that. Definitely next. > > 3) Configuration - now that things are working, I'll need to find a way to > expose some configuration things. Specifically around things like number of > connections to hold open, number per target/host, thread pools, etc…. > > 4) Flip the logging and such to using our normal Logging framework. > > 5) Move it all from the sandbox to trunk. > > > Anyway, definitely getting closer. :-) > I am completely buried under with work at my day job (the one that helps me pay the bills) and am unlikely to be able to find a lot of time to write code but will happily assist with HC specific issues. Just let me know. Cheers Oleg > > Dan > > > > On Aug 6, 2012, at 10:43 AM, Oleg Kalnichevski <[email protected]> wrote: > > > On Fri, 2012-08-03 at 09:17 -0400, Daniel Kulp wrote: > >> On Friday, August 03, 2012 11:29:41 AM Oleg Kalnichevski wrote: > >>>> I just went through and added a little bit of error handling into it as > >>>> well. Mostly around a connection refused exception and for read > >>>> timeouts. For the read timeout, I DID have to add an ioct.shutdown() in > >>>> the SharedInBuffer consume method when read or it kept getting called > >>>> repeatedly since we didn't read anything. > >>> > >>> Hmmm. This should not be necessary. It is the responsibility of the > >>> protocol handler to shut down things properly if connection goes down or > >>> something breaks at runtime. In case of an I/O timeout the protocol > >>> handler always shuts down the execution handler, which in its turn > >>> should shut down shared i/o buffers [1]. I'll look into it. > >> > >> Well, it's mostly because I didn't actually set the timeouts on the > >> connection at all. Haven't figured that out yet mostly due to the same > >> issus as with the SSL/connection timeouts/etc... as we set them on a per- > >> request basis normally. For now so things don't "hang", I just added > >> timeouts on the wait(...) calls we use when we need to block for > >> additional > >> IO. In that case, the wait(...) times out and I need to shutdown the > >> buffers and such manually so when the data DOES eventually arrive, we > >> ignore > >> it. Setting the "real" timeouts on the connections would definitely help. > >> > > > > > > Hi Daniel > > > > I tweaked the code a bit to make sure i/o timeouts (both connect and > > receive ones) are handled correctly and can be specified on a per > > request basis overriding the defaults. Please review / verify. > > > > I also added connection pool lease / release logging. I am no longer > > seeing anything suspicious related to connection management. When > > executing requests sequentially the connection manager allocates one > > connection only. > > > >>>> 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? > > > > Oleg > > > > >
