On Thursday, May 30, 2013 at 4:15 AM, Daniel Kulp wrote:
>
> On May 27, 2013, at 10:14 PM, Willem jiang <[email protected]
> (mailto:[email protected])> 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
> [email protected] - 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
