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 buffers. > > BTW: I think the NHttpClient.java referenced from: > http://hc.apache.org/httpcomponents-core-ga/examples.html > 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. Oleg
