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 <[email protected] > (mailto:[email protected])> 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 > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com
