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 Tue, 28 May 2013 02:14:22 GMT
Hi Dan,

Please check out my comments in line.  

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




On Tuesday, May 28, 2013 at 10:05 AM, Daniel Kulp wrote:

>  
> On May 26, 2013, at 11:54 PM, Willem jiang <willem.jiang@gmail.com (mailto:willem.jiang@gmail.com)>
wrote:
>  
> > Hi,  
> >  
> > As you know Netty[1] provides excellent supports of NIO and you can still get the
full control of protocol handler. It could be useful if we provides a Netty transport of CXF.
>  
> Are you proposing some sort of proprietary Netty transport or are you thinking of using
Netty's HTTP stuff to create another HTTP implementation for CXF?

It just leverage the Netty HTTP implementations.   
>  
>  
> >  
> > 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 :)   
>  
>  
>  
> > 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.  
>  
>  
> --  
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com




Mime
View raw message