cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: Async http client experiments....
Date Mon, 30 Jul 2012 20:40:32 GMT
On Mon, 2012-07-30 at 10:35 -0400, Daniel Kulp wrote:
> 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.  :-)
> 

Hi Daniel

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. 

> 
> > 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!
> 

You are probably helping me as much as I am helping you.

Cheers

Oleg



Mime
View raw message