One more thing....
Of course, the most important thing from all this work is...
What affect does it have on the time to build CXF? After all, it's all about
me.... :-)
Running "mvn -T 8 -Pnochecks" from a prebuilt tree on my 4 core laptop:
2.3.x branch:
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 11:04.667s (Wall Clock)
Trunk:
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 9:45.506s (Wall Clock)
And trunk has extra stuff like the jibx databinding and the logbrowser stuff.
Super cool. I haven't seen CXF build and test in under 10 minutes in a VERY
long time. Now we can all be 10% more productive. :-)
Dan
On Friday 04 March 2011 3:58:42 PM Daniel Kulp wrote:
> I forgot to mention one other huge advantage to all of this...
>
> One of the issues I keep having when deeling with customers and new users
> and such, expecially of some of the advanced things, is the question of
> "what META-INF/cxf/ files do I need to import for my application?"
> We've done a pretty poor job of documenting exactly what you need and
> when. For example, I know when Dennis was writing his dev works
> articles, he sent me a couple test cases that were not working, but adding
> additional imports in (for things like ws-a and such) just made them work.
>
> Now they are all gone. :-) Just import cxf.xml and, if in a servlet
> environment, cxf-servlet.xml (for now, I want to get rid of that next).
> Done. Everything just works. :-)
>
> A techical/code solution to a documentation problem. That's kind of
> backwords. :-)
>
>
> Dan
>
> On Friday 04 March 2011 3:47:55 PM Daniel Kulp wrote:
> > I just committed the gigantic refactoring of the Spring bus stuff to base
> > it on the ExtensionManagerBus. I'll describe it in a minute, but first
> > the performanc result on my test case:
> >
> > Running test - 2.4.0-SNAPSHOT
> > Setup: 29105 51/sec
> > Invoke: 38174 39/sec
> > Setup config: 39026 38/sec
> >
> > Compared to the 2.3.3:
> > > Running test - 2.3.3
> > > Setup: 49732 30/sec
> > > Invoke: 62276 24/sec
> > > Setup config: 56164 26/sec
> >
> > As you can see, it's quite a bit faster across the board now. That's
> > great. The code is also (IMO) a LOT simpler now. We no longer have to
> > modify both bus-extension.xml and cxf-extension-blah.xml files. The
> > extension loading is more unified. The extension retrieval from the Bus
> > is simpler and, for the most part, identical between the Spring and
> > Non-Spring cases. And the performance rocks. :-)
> >
> > For the most part, it's simple to modify existing applications to work.
> > Just remove all the imports for everything except META-INF/cxf/cxf.xml
> > and META- INF/cxf/cxf-servlet.xml if you use a servlet. However, there
> > are a couple of other "gotchas" that I encountered:
> >
> > 1) We had several files that did something like:
> >
> > <bean id="cxf" class=".... CXFBusImpl>
> >
> > ... conifure some interceptors....
> >
> > </bean>
> >
> > That no longer works. The proper way to do that has been to use the
> > <cxf:bus> namespaced object. It's been that way for a while. Creating
> > separate Bus's like that is just asking for having things become
> > confused. I converted all the tests to do that properly. You COULD
> > potentially change that to:
> > <bean id="cxf" class="org.apache.cxf.bus.spring.SpringBus">
> > but using cxf:bus is definitely the better way to go. Directly
> > instantiating and depending on internal "impl" classes and such is
> > generally a bad idea.
> >
> > 2) depends-on and injections - since almost none of the CXF internal
> > beans are now defined in the Spring context, you cannot really depend on
> > them directly. That's not a normal thing anyway. The Bus is really
> > the only thing that is in the context.
> >
> > In anycase, the rest was fairly simple. If you do define beans in the
> > spring config, they will override/replace the auto loaded stuff (just
> > like before), the configurations stuff remains the same, etc.... It
> > just starts up a ton faster and uses a bit less memory. :-)
> >
> > I definitely have some more testing to do, but I think it's a good start.
> >
> > Dan
> >
> > On Thursday 03 March 2011 5:01:58 PM Daniel Kulp wrote:
> > > I've done quite a bit of work now on trunk to speed up the "normal" use
> > > cases. With what's on trunk now, a normal JAX-WS client that doesn't
> > > include any spring config will get the extension bus instead. With my
> > > lastest set of changes, a default extension bus now starts up without
> > > ANY XML parsing and very few beans and such created. This is MUCH
> > > faster now. I wrote a little benchmark based on the java-first-jaxws
> > > example (to avoid any WSDL related things) and depending on cxf-bundle
> > > to make
> > >
> > > sure we get EVERYTHING and then does:
> > > public static void doIteration(boolean invoke) {
> > >
> > > BusFactory.setThreadDefaultBus(null);
> > > BusFactory.setDefaultBus(null);
> > >
> > > Service service = Service.create(SERVICE_NAME);
> > > String endpointAddress = "http://localhost:9000/helloWorld";;
> > > service.addPort(PORT_NAME,
> > >
> > > SOAPBinding.SOAP11HTTP_BINDING, endpointAddress);
> > >
> > > if (invoke) {
> > >
> > > service.getPort(HelloWorld.class).sayHi("Hello");
> > >
> > > } else {
> > >
> > > service.getPort(HelloWorld.class);
> > >
> > > }
> > >
> > > }
> > >
> > > in a loop under 3 conditions:
> > > 1) First is with invoke=false to basically time all the upfront setup
> > > costs. That includes creating the Bus, creating the Service, and then
> > > creating the Proxy.
> > >
> > > 2) Then with invoke=true to include the additional stuff of creating
> > > the interceptor chains and conduits and doing a real invoke.
> > >
> > > 3) Again with invoke=false, but this time with specifying a spring
> > > config file (cxf.xml). This basically is the same as (1), but
> > > involves the spring Bus now.
> > >
> > > I then ran this with several versions of CXF. Results are below.
> > > (first number is the # of ms for 1500 iterations, then it's
> > > iterations/sec)
> > >
> > > Basically, the Extension bus stuff is now a TON faster. For 80% of the
> > > use cases, it's much faster. I'm definitely excited about that.
> > > The spring case slowed down a bit. I'm not sure why. I'll need to
> > > profile that a bit to figure it out. In anycase, for standalone
> > > applications and cases where config is done through API's, this is
> > > quite a bit faster. As we start thinking about Blueprint and such,
> > > this can be important. Right now, the server side parts are all very
> > > spring based and thus won't benefit from this.
> > >
> > > :-(
> > >
> > > One thing I'm going to try next is making META-INF/cxf/cxf.xml just
> > > have a single bean (the ExtensionBus) and removing all the
> > > cxf-extension-*.xml files (except for the HTTP things, more in a sec on
> > > that) and seeing what happens.
> > >
> > > The HTTP stuff on the server side becomes a "challenge". Right now,
> > > we have basically 3 implementations of the HTTPDestinationFactory:
> > > jetty, servlet, and OSGi. The user pretty much selects the one they
> > > want by importing the appropriate cxf-extension file and not the
> > > others in their spring config. While it works, there is a down side:
> > > you can only have one implementation in you application. Normally
> > > not a problem, but there IS the use case of a Servlet based
> > > application that may also want a service or two exposed on a specific
> > > jetty port (like maybe for a decoupled client) that isn't under the
> > > servlet containers control.
> > >
> > > My proposal for that would be to put a single HTTPDestinationFactory in
> > > the http module that would hold onto a DestinationRegistry. The OSGi
> > > and Servlet based things would just grab that DestinationRegistry for
> > > their dispatching. However, when the HTTPDestinationFactory is asked to
> > > create a destination for a "full" URL (like
> > > "http://localhost:8080/blah";) instead of a path (like "/blah"), it
> > > would call on a delegate that the Jetty stuff would provide to it. I
> > > need to think about this a bit more, but I think it would work fairly
> > > well.
> > >
> > >
> > > Dan
> > >
> > >
> > >
> > >
> > > Running test - 2.4.0-SNAPSHOT
> > > Setup: 29086 51/sec
> > > Invoke: 42558 35/sec
> > > Setup config: 69839 21/sec
> > >
> > >
> > > Running test - 2.3.3
> > > Setup: 49732 30/sec
> > > Invoke: 62276 24/sec
> > > Setup config: 56164 26/sec
> > >
> > > Running test - 2.3.0
> > > Setup: 44233 33/sec
> > > Invoke: 56496 26/sec
> > > Setup config: 55305 27/sec
> > >
> > > Running test - 2.2.12
> > > Setup: 48193 31/sec
> > > Invoke: 55737 26/sec
> > > Setup config: 50582 29/sec
> > >
> > >
> > > Running test - 2.1.9
> > > Setup: 43944 34/sec
> > > Invoke: 47652 31/sec
> > > Setup config: 44550 33/sec
> > >
> > >
> > > Running test - 2.1.1
> > > Setup: 47335 31/sec
> > > Invoke: 48871 30/sec
> > > Setup config: 49255 30/sec
--
Daniel Kulp
[email protected]
http://dankulp.com/blog
Talend - http://www.talend.com
