cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Async http client experiments....
Date Mon, 30 Jul 2012 14:35:25 GMT
On Sunday, July 29, 2012 12:59:15 PM Oleg Kalnichevski wrote:
> All right. Then, with your permission, I'll try to commit some of my
> changes. You can always revert or re-work them if anything is not to
> your liking.

Yep.  That's the purpose of version control.   :-)  Major thanks for taking 
a look.  That's a huge help.

 
> I think I have found the problem. It appears to be a classic
> thread-safety issue. Content codecs (ContentEncoder / ContentDecoder
> instances) are not thread-safe and are not meant to be accessed by
> worker threads directly. 

OK.  I actually thought about that originally when I wrote the code.  
However, I didn't see anything in the javadocs for HttpAsyncRequestProducer 
or for the Encoder saying they shouldn't.   Since you can use the IOControl 
object to suspend the input, I assumed you would need to keep the IOControl 
to resume it and thus IT should be usable on multiple threads.  If one is 
usable, I thought the other should be as well.

IMO, it would be a HUGE help if the javadocs would be updated to 
specifically say something like:

"The encoder should only be used within the context of the call to 
produceContent.   The IOControl object can be retained and used on other 
threads to allow resuming events when appropriate." 

Likewise for the decoder if appropriate there as well.  If that was in the 
javadoc, I wouldn't have written it like I did.  :-)


> Worker threads are expected to use shared
> buffers to produce and consume message bodies and let the I/O dispatcher
> take care of transferring data from and to the underlying channel
> (through a content codec) instead of trying to force data in or out of
> the content codec directly. The reason why content codecs are not meant
> to be shared is to minimize the chances of blocking the I/O dispatch
> thread and all other connections on the same I/O selector along with
> it.
> 
> I'll see if I can re-work your code a little and fix the threading
> issue.

OK.  Thanks for that.   I'll take a look as well.

Major thanks for jumping in and taking a look and providing good 
explanations.  Huge help!


-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

Mime
View raw message