The following features are expected

• Support for list-timers command in a cluster
• Support for migrate-timers command in a cluster

Feature decription

This feature adds support for listing and manually migrating EJB Timers in a clustered environment.  The tests use derby network database server and jdbc/_default as timer service datasource.  Before running the test, need to make sure table EJB_TIMER_TBL is either empty or does not exist.

To check it in ij:  select OWNERID from EJB_TIMER_TBL;

To delete all rows: delete from EJB_TIMER_TBL;

Doc Impact:

For migrate-timers command, --destination option in v2 is now changed to --target in 3.1.

Other aspects of documents for list-timers and migrate-timers remain the same as in v2.

Test Description

Test execution

• cd v2/appserv-tests/
• svn update
• cd devtests/ejb/ee/timer/cli
• ant all

What does the test do

• build
  • compiles and build a test ejb-jar located in appserv-tests/build/module/archive/ee-timer-create.jar.  It contains 2 singleton beans: StartupSingletonBean and CreateTimersBean.  Deploying this ejb-jar is done in test class as part of runTest() method, not in build.xml.  After deployment, StartupSingletonBean's post-construct method invokes CreateTimersBean to create a programatic timer.  After running test, this ejb-jar is also undeployed as part of runTest() method, and all associated timers will be deleted by the container.
• setup
  • start derby database
  • start domain
  • set timer-datasource=jdbc/__default in default-config
  • set up a cluster (named cluster) with 2 instances (in1 and in2), and a standalone instance (in3).  These names are configured in ./build.properties
  • create-resource-ref in cluster1 and in3, to be used by timer service
• run
  • list-timers: execute tests contained in timer/cli/src/eetimer/ListTimerTests.java
    • deploy test ejb-jar to cluster1
    • listTimersCluster: run list-timer --target cluster1, expecting in1 has 1 timer and in2 has 1 timer.
    • listTimers: run list-timer without no target, so default target DAS is used, expecting 0 timer is returned since the test ejb-jar is not loaded in DAS.
    • listTimersInstance3Empty: run list-timer --target in3, expecting 0 timers in in3.
    • undeploy test ejb-jar from cluster1
    • deploy test ejb-jar to in3
    • listTimersInstance3: run list-timer --target in3, expecting 1 timer in in3
    • undeploy test ejb-jar from in3
  • migrate-timers:
    • calls -disable-gms target to disable gms.  When gms is disabled in a cluster, automatic timer migration does not kick in when stopping a clustered instance, so we can test the (manual) migrate-timers command.
    • execute tests contained in timer/cli/src/eetimer/MigrateTimerTests.java
      • deploy test ejb-jar to cluster1
      • migrateTimers: stop in1 and migrate in1's timer.  No target is specified, defaults to DAS, the container will pick a running instance from the same cluster, and it should be in2.  Expected result is 0 timers in in1 and 2 timers in in2
      • migrateTimersWithTarget: stop in2 and start in1, migrate timers from in2 to in1.  Expected result is 0 timers in in2 and 3 timers in in1.  When in1 starts, another timer is also created, and that's why there are now 3 timers.
      • migrateTimersOutsideCluster: a negative test to make sure timers cannot be migrated across cluster.
      • undeploy the test ejb-jar

• unsetup
  • unsetup-cluster (stop and delete the cluster)
  • stop-database
  • stopDomain

Executing test is separate steps

• ant build
• ant setup
• ant run
• ant unsetup