Reorganizing clustering testsuite

brian.stansberry Jul 15, 2007 11:11 AM

The clustering testsuite is somewhat disorganized and takes far too long to run. The "far too long to run" problem is mostly due to repeating tests multiple times under different configs (REPL_ASYNC vs REPL_SYNC, buddy replication or not, UDP/TCP/TCP_NIO). Some tests get executed 9 times!! Some of this duplication is valid, but much of it isn't.

I'm going to go through and determine for which tests there is benefit from execution under different configs. I'll then organize the testsuite into packages such that it's easy to create ant patternsets to specifically target groups of tests for a particular config. Then update the testsuite build.xml to properly invoke the more limited patternsets.

1. Re: Reorganizing clustering testsuite

belaban Jul 16, 2007 1:38 AM (in response to brian.stansberry)

We have already organized the JGroups test suite accordingly, e.g. 'functional tests' which don't require a stack are run only once.

We're also looking at using either testng or junit 4 for JGroups 2.6. Obe benefit for example is that, for each test class, you need to create a channel and connect to the group only *once*, which slashes the duration of a test run too.
Actions
2. Re: Reorganizing clustering testsuite

brian.stansberry Jul 16, 2007 10:49 AM (in response to brian.stansberry)

Another thing that would help is being able to specify in jboss-web.xml what cache to use. Right now it's fixed.

This would eliminate the need to stop and restart the servers in order to test REPL-SYNC, FIELD, non-default BuddyReplication, etc. All these variations are really variations on the cache config. Rather, the test would deploy an appropriate cache into the standard server configs and the test wars would use it.

At this point a stop and restart of the 2 cluster nodes is roughly a 5 min process. That should drop as AS 5 gets more polished, but eliminating all the restarts will save a lot of time.

The above is further down the road though. Should be done as part of an overall solution to intelligent webapp cache deployment, one that includes the ability to deploy the cache as an intrinsic part of the webapp deployment.
Actions

Go to original post