cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem jiang <willem.ji...@gmail.com>
Subject Re: Netty transport for CXF
Date Thu, 30 May 2013 01:53:19 GMT



On Thursday, May 30, 2013 at 4:15 AM, Daniel Kulp wrote:

>  
> On May 27, 2013, at 10:14 PM, Willem jiang <willem.jiang@gmail.com (mailto:willem.jiang@gmail.com)>
wrote:
> > > > I just did a prototype of support Netty transport for CXF, it include
the server side implementation and client side implementation. And I did some performance
compare tests by running the wsdl_first from examples with Jetty transport and Netty transport
and using Jmeter to send the requests. The test results are much similar, Netty transport
and Jetty transport can hit the highest processing recorder with the throughput of 9M per
second in my MacBookPro. I only performance turning I did was just changing the thread pool
size of ExecutionHandler which will be used to call the whole soap stake of CXF.
> > >  
> > >  
> > >  
> > > When I looked at Netty's HTTP client stuff (over a year ago now), I had MAJOR
problems getting it to stream large messages. The small messages worked great and did have
good performance, but once we could no longer buffer the whole message and wanted to get it
streaming in chunks, I could never get it working. That said, that was a long time ago and
they may have fixed all the bugs related to that.
> > The test that I did just one the server side and no chunk encoding involved.
> > We can polish it if we need :)  
>  
>  
>  
> Just checked. If the size of the message sent from the client exceeds the chunk threshold,
nothing gets sent over the wire at all. :-( The client then just hangs and eventually times
out. Didn't really look into what is needed yet.

I will dig this issue next week when I finish the SSL support of the netty.  
>  
>  
> > > > I'd like to commit the prototype into Apache CXF trunk, and we could polish
the transport together :)
> > > > Any thought?
> > >  
> > >  
> > >  
> > >  
> > >  
> > > Sure. On the client side, if it's sticking to HTTP, I'd like to see it plug
into the HTTPConduit like the async client version does. That's something we could work on
though. Speaking of asyncclient version, they supposedly have a new version that is supposedly
significantly faster. On my todo list to look at. :-(
> > Yes, it do the same thing as the async client does.
> > I will commit the code shortly today.  
>  
>  
>  
> We'll likely need to figure something out. With your changes to distribution, both async
and netty clients are in the lib dir and it would then be whichever one is found on the classpath
first.  
>  
I've been thinking about it for a while, maybe we should introduce some schemes as camel does,
such as "abc", "netty", etc. if the client want to use async http client, he could specify
the address with "ahc:http://example.com/server" and if he want to use netty he could use
"netty:http://example.com/server", if he uses "http://example.com/server" we just let the
class path decide which client will be used.

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




--  
Willem Jiang



Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://www.fusesource.com | http://www.redhat.com
Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English)
http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese)
Twitter: willemjiang  

Weibo: 姜宁willem  



Mime
View raw message