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
