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 Mon, 30 Jul 2012 21:41:55 GMT
On Mon, 2012-07-30 at 17:06 -0400, Daniel Kulp wrote:
> On Monday, July 30, 2012 10:40:32 PM Oleg Kalnichevski wrote:
> > Individual ContentDecoder / ContentEncoder implementations are marked
> > with @NonThreadSafe annotation but public APIs do not make it clear
> > enough that codecs are not thread safe. Thank you for pointing that out.
> > I'll update javadocs and the tutorial as you suggested.
> Well, the @NonThreadSafe annotation wouldn't have really helped me I think.   
> *I'm* only accessing the given encoder/decoder on a single thread.   Thus, 
> from my standpoint, it should have worked.  :-)    Yea, that single thread 
> is different than the  thread that passed it to me, but it is all on a 
> single thread.  

This correct. However, there is also a I/O dispatch thread of the I/O
reactor that writes out content of the session buffer as soon as the
underlying channel becomes writable. Chunks headers can get corrupt if
both the I/O reactor and the worker thread happen to access the buffer
at the same time. This also explains why you have never seen data
corruption with Content-Length delimited messages, as in this case data
gets written to the underlying channel directly bypassing all

> 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


View raw message