cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <>
Subject Re: Async http client experiments....
Date Wed, 01 Aug 2012 15:58:23 GMT
On Mon, 2012-07-30 at 19:47 -0400, Daniel Kulp wrote:
> On Monday, July 30, 2012 11:41:55 PM Oleg Kalnichevski wrote:
> > On Mon, 2012-07-30 at 17:06 -0400, Daniel Kulp wrote:
> > > BTW: I think the referenced from:
> > >
> > > needs work as well.   I don't think most of the parameters set in the
> > > HttpParams actually will actually go into effect.   That was part of my
> > > original issue as the TCP_NODELAY setting didn't take effect until I set
> > > that on the ConnectingIOReactor instead of in the params.    Not sure if
> > > it's a bug in the BasicNIOConnPool that was ignoring the params or a bug
> > > in the example.    Looking at the code in BasicNIOConnPool, I think the
> > > connection timeout is the only setting that would work from the params.
> >
> > Higher level components such as HttpAsyncClient usually take care of
> > creating and initializing the I/O reactor based on the HTTP level
> > parameters. When using core components directly more work may be needed.
> > I/O reactor config in NHttpClient is obviously wrong. TCP_NODELAY should
> > actually be set to true per default, which is something I clearly
> > overlooked.
> I was JUST about to ask about that.  :-)     false is OK for GET requests, 
> but for PUT/POST, it completely kills performance as it adds up to a 200ms 
> delay between sending the headers and the body as it waits for the ack of 
> the headers.   Would you like me to log some issues in JIRA for these so 
> they get tracked?

Hi Daniel

I believe I have fixed the thread synchronization issue. All tests
repeatedly passed for me. Could you please have a look at my changes and
confirm that everything is more or less sane and HTTP transport still
performs at an acceptable level?

As the next I could optimize the code and hopefully bring its
performance closer to that of the default blocking transport.

I also noticed that for some reason additional connections get open and
closed without transmitting any data, which obviously should not be
happening. I'll investigate the problem if you confirm that you want me
to proceed.



View raw message