Hi Sergey, The difference comes from underlying Undertow and Netty, they are different.
AFAICS, the main goal for Netty is an aync nonblock network IO framework, though Netty provide a lot more than that. On the other hand, the main goal for Undertow is a flexible, lightweight, embedded web server, so Undertow and Netty are on different layer. The IO framework used by Undertow is XNIO[1], IMO the XNIO is the counterpart of Netty used by Undertow. Here is the faqs[1] why undertow use XNIO but not Netty as IO framework. [1]http://xnio.jboss.org/ <http://xnio.jboss.org/> [2]http://undertow.io/undertow-docs/undertow-docs-1.3.0/index.html#undertow-faq <http://undertow.io/undertow-docs/undertow-docs-1.3.0/index.html#undertow-faq> Best Regards －－－－－－－－－－－－－ Freeman(Yue) Fang Red Hat, Inc. FuseSource is now part of Red Hat > On Feb 26, 2016, at 5:43 PM, Sergey Beryozkin <[email protected]> wrote: > > Hi Freeman > > Just curious, what is the difference between Netty and Undertow CXF > transports ? > > Thanks, Sergey > > > On 26/02/16 04:03, Freeman Fang wrote: >> Hi Team, >> >> I just push commit to master to add cxf http-undertow transport. >> >> This is pretty much like how the cxf http-jetty transport works but start an >> embedded undertow server instead when launch a standalone cxf/camel-cxf >> endpoint. >> >> As in Apache Camel there's already a camel-undertow component and in the >> upcoming Karaf 4.1(which will use OPS4J PAX-WEB 6), there's also an undertow >> http-osgi service implementation, so I think it should be good in CXF we >> also has a http-undertow transport so that end user has more option to chose >> the http transport they wanna use. >> >> Most configuration which works for jetty engine like >> threading/TLS/maxIdleTime/continuationsEnabled/handlers/host/port are still >> works for undertow(of course here handler is the undertow style handler but >> not the jetty handler), however the sendServerVersion/connector/reuseAddress >> not applicable anymore in undertow(I will add a doc page soon). >> >> For the end user who ever use http-jetty transport, if they wanna try the >> http-undertow transport, they just need change the dependency from >> cxf-rt-transports-http-jetty to cxf-rt-transports-http-undertow, and change >> the configuration xml(if there’s any) namespace to the undertow one. >> e.g. replace >> xmlns:httpj="http://cxf.apache.org/transports/http-jetty/configuration” >> with >> xmlns:httpu="http://cxf.apache.org/transports/http-undertow/configuration"; >> >> In the patch file I appended with CXF-6800 I just follow this way using a >> script to replace the namespace in configuration files and those existing >> system tests running against the http-jetty just passed with http-undertow. >> >> >> NOTE, my commit to community master not change the existing system tests as >> I do in the patch appended with CXF-6800(That’s just the tests on my own >> branch so that I’m confident everything works with http-undertow as well). >> Also I ran camel-cxf related test against http-undertow transport and they >> passed. >> >> My commit have two new modules >> >> rt/transports/http-undertow >> This is similar as the rt/transports/http-jetty, but no Undertow specific >> Continuation Provider/Wrapper because we reuse the general >> Servlet3ContinuationProvider which will call into Undertow implementation of >> Servlet3 async api. >> >> systests/transport-undertow >> Where I revise several http-jetty system test to demonstrate how the >> https/Session/Continuation(Servlet3 async api implementation in >> undertow)/ThreadPool/Undertow Handlers(for BasicAuthTest and DigestAuthTest) >> works and configures with http-undertow. >> >> Any feedback is appreciated. >> >> Thanks! >> －－－－－－－－－－－－－ >> Freeman(Yue) Fang >> >> Red Hat, Inc. >> FuseSource is now part of Red Hat >> >> >> >> >
