Testsuite changes

[brian.stansberry]

Just an FYI on some stuff I'm doing that affects the way the clustering tests work.

The following is currently in place in Branch_4_0 and will be moved to HEAD soon.

Previously the clustering tests worked by creating 2 configs "node0" and "node1" and launching 2 jboss instances, one using each.

To execute all the required tests, the build script would tear down and rebuild node0 and node1, altering various aspects of the config (e.g. use REPL_SYNC instead of REPL_ASYNC).

The problem with this is that when a version of node0/1 got torn down and replaced, it's server logs went with it. This makes subsequent debugging of any failures difficult, particularly with cruisecontrol runs that sometimes reveal problems we don't see on our local machines.

This is a real problem right now, as cc is starting to use jrockit, and odd failures are appearing. I don't run jrockit at home, so hard to diagnose w/o logs.

To fix this, I'm no longer using "node0/node1". Rather, each config will be given a name that somewhat describes what it is, e.g.:

cluster-UDP-0 and cluster-UDP-1
cluster-field-UDP-0/1 (configured for FIELD repl)
cluster-UDP-SYNC-0/1 (configured for REPL_SYNC)
cluster-field-UDP-SYNC-0/1
cluster-UDP-BR-0/1 (configured for BuddyReplication)
cluster-field-UDP-BR-0/1

[ben.wang]

Good idea. While we are on this subject, I have noticed that tests-clustering is taking a while to run becuase of number of tests included.

Sometimes I find that I only need to run one configuration set, e.g., don't care about UDP, BR, and repl mode, just for development testing purpose. What will be the best way to do this without long waiting? :-)

[brian.stansberry]

I should just refactor the tests-clustering target a bit so it calls multiple sub-targets for each of the main sets. Then you could just call the sub-target you want.

It would be better to have the non-http tests in a separate sub-target from the default http ones too, but right now they share the same server start/stop cycle. Making separate sub-targets would add yet another start/stop cycle.

[brian.stansberry]

If anyone can add a "one-test-clustering" target, they'll be my friend for life :)

I spent a few hours trying to do that once, but hit a roadblock and gave up.

[brian.stansberry]

I've added a 'one-cluster-test' target. It took 5 mins; no idea why I had trouble before.

Example use:

build -Dtest=org/jboss/tests/cluster/partition/test/* one-cluster-test

It takes whatever you set the 'test' system property to and makes an ant patternset out of it. Then starts the 2 servers in the standard "all" config (UDP, REPL_ASYNC, default BR setting for the branch) and executes all the tests in the patternset.

The name 'one-cluster-test' is inaccurate, since it will run as many tests as your patternset includes.

No ability for other configs (field, REPL-SYNC, non-default-BR) at this point.

Ben, when I get some cycles I'll do the bit you mentioned about easily running all the field tests, etc.

[brian.stansberry]

Added the ability to run single tests with other transports than UDP.

This works differently in Branch_4_0 than HEAD, due to differences in the way JGroups is configured when the multiplexer is used.

Branch 4.0

Same as described above, but use the "one-cluster-test-tcp" target instead of "one-cluster-test". No option to use TCP_NIO.

HEAD

As follows:

build -Dtest=org/jboss/tests/cluster/partition/test/* -Djboss-junit-configuration=tcp one-cluster-test

where the value of jboss-junit-configuration is one of the different stacks available in multiplexer-stacks.xml, i.e.

udp
tcp
tcp_nio

At this point it isn't possible to use udp-sync, tcp-sync or tcp_nio-sync.

If the property isn't set, the default "udp" is used.