On May 26, 2013, at 11:54 PM, Willem jiang <[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? > > 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. > 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. :-( -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
