cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Faster CXF builds and test ports....
Date Thu, 03 Jun 2010 20:43:51 GMT

Actually, I discovered a better way to handle the dynamic ports:

Since a LARGE LARGE majority of our tests that need ports go through the 
ClientServer infrastructure in testutils, it was fairly easy to add some level 
of dynamic port support to there.    I've now converted all the systest/jaxws 
and systest/databinding tests to use dynamic ports using this and it seems to 
work fairly well.  

Basically, prior to calling the launchServer(...) stuff, the client makes a 
quick call to allocatePort(...) or TestUtils.getPortNumber(...) (the later if 
it doesn't subclass the ClientServerTestBase stuff) which will allocate the 
port and record it based on the information passed in. (I normally use the 
servers class as the name)   In launchServer, the server that is forked gets 
all the allocated ports passed to it as system properties.  Thus, when the 
server needs a port, it also calls the allocatePort thing using the same name 
and it gets back the value that the test produced. 

Also, since everything is stored in system properties, this works well with 
the Spring PropertyPlaceholderConfigurer.   The beans.xml things that define 
the URL's can easily be updated to use the dynamic ports as well.  Just add 
the configurer bean and then use something like:


to define the location.  

Anyway, as I mentioned, I now have all of jaxws and databinding system tests 
updated to use dynamic ports.   I'll probably tackle the other systest things 
and the http-jetty transport module tomorrow.   I'm not sure what else needs 
to be looked at.  Probably the JMS transport.

The JMS transport has another issue I'm not sure how to resolve yet.    The 
jms:address extensor in the wsdl can contain the jndi url to the broker 
(jndiURL=tcp://localhost:61500) which would need to be updated somehow as 
well.   I still need to figure that one out.   :-(


On Thursday 03 June 2010 12:36:34 pm Daniel Kulp wrote:
> As some of you may have noticed, I've been doing some commits to make
> things work better with the Maven 3 betas.   One reason is to achieve
> faster builds. My new notebook has 4 cores (8 threads) and 12GB of RAM and
> I'd like to get to a point where they are useful.  :-)
> Maven 3 has a "parallel" mode (abbreviated // )  where it can build non-
> dependent projects in parallel.  That would allow better use of extra cores
> and such.   With my latest changes along with an update to the Checkstyle
> plugin which I committed to Maven yesterday, (needs the snapshot version
> which isn't deployed yet) I can now build CXF in // mode as long as the
> tests are off:
> mvn clean
> mvn install -Dmaven.test.skip.exec=true -T 12
> The // mode cuts about a minute and a half off the install.  (from 6.5
> minutes down to 5 minutes) which is good.  Subsequent  "mvn -Pfastinstall"
> builds drop from 43 seconds to 34 seconds.   Also good.
> However, the real win will be if I can get the tests running in parallel as
> well.     The major problem with the tests is the port usage.   We pretty
> much use ports in the 9000-9100 range for everything with MANY tests using
> the same ports.   One reason is that we use the ports burned into the
> wsdl's rather than overriding them as part of the test  cases.   Thus, I'd
> like to start going through the tests and get them to override the wsdl
> specified ports with unique ports.   Now, the question comes: how to
> allocate the ports.   There are basically two options:
> 1) Assign each module a "range" of ports to use and update the tests to use
> that range.
> 2) Use the buildhelper:reserve-network-port maven plugin to try and
> dynamically allocate some ports and somehow get them passed into the test
> suites to use.
> (1) is definitely easier, but I kind of like (2).   I might try and get the
> buildhelper thing to allocate a range of like 10 ports per module and save
> them to a properties file or something and update the testing harness
> things to load them up to make them avail.   Not really sure yet.
> The other trick thing will be the non-http ports we use in the tests. 
> Mostly, that is the JMS broker stuff and the CORBA binding IOR things.  
> Those may also require some extra investigation.
> Anyway, just wanted to provide a quick update on the progress.   :-)

Daniel Kulp

View raw message