cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Async http client experiments....
Date Thu, 01 Jan 1970 00:00:00 GMT
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.
> > 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 thought about a new factory per request, but the pool seems to
> > 
> > be tied to the connection factory  as well and a full pool per request
> > would be aweful.   I then wanted to see if I could pass some sort of
> > contextual object in (there is that BasicHttpContext object) that I
> > could pull information out of at connection time or similar, but I
> > could really figure out where that went, at least not until after the
> > IOSession is setup, which is too late.   Also thought about a thread
> > local, but that doesn't work with the async connection.
> I'll try to find time to write all the necessary plumbing code on this
> weekend.
> Cheers
> Oleg
> > Any ideas on that would be a huge help.  I'll keep digging a bit as
> > well.
> > Kind of learning more about the HC stuff and NIO and all kind of things,
> > which is kind of fun.   :-)
> [1]
> ttp/nio/protocol/HttpAsyncRequestExecutor.html#269 [2]
> ttp/nio/protocol/HttpAsyncRequestExecutor.html#124
Daniel Kulp -
Talend Community Coder -

View raw message