[JBoss JIRA] (JBTM-576) update unit tests
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-576?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson reassigned JBTM-576:
----------------------------------
Assignee: Tom Jenkinson (was: Gytis Trikleris)
> update unit tests
> -----------------
>
> Key: JBTM-576
> URL: https://issues.jboss.org/browse/JBTM-576
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Testing
> Affects Versions: 4.7.0
> Reporter: Jonathan Halliday
> Assignee: Tom Jenkinson
> Priority: Minor
> Fix For: 5.0.0.Final
>
>
> There are many unit tests that have lain dormant for some time. Convert them from DTF/junit3 to junit4, wire them to the build and make them pass.
> This will be done incrementally, one module at a time, following the dependency chain e.g. common, ArjunaCore/arjuna, ArjunaCore/txoj, ... JTA/, .../JTS/...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (JBTM-1147) Refactor ParticipantCompletion recovery tests to remove duplicate rules
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1147?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1147:
--------------------------------
Fix Version/s: 5.0.0.M2
(was: 5.0.0.Final)
> Refactor ParticipantCompletion recovery tests to remove duplicate rules
> -----------------------------------------------------------------------
>
> Key: JBTM-1147
> URL: https://issues.jboss.org/browse/JBTM-1147
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: XTS
> Affects Versions: 4.16.4, 5.0.0.M1
> Reporter: Paul Robinson
> Assignee: Amos Feng
> Priority: Minor
> Fix For: 5.0.0.M2
>
>
> The Byteman rules for the participant completion XTS recovery tests have many rules that are almost duplicates of each other. For example:
> The following rules in BACrashDuringCommit could be refactored into a single rule
> {code}
> #####################################################################
> # Setup counter MultiParticipantParticipantCompletionParticipantCloseTest
> #
> RULE setup counter MultiParticipantParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> #####################################################################
> # Setup counter MultiParticipantCoordinatorCompletionParticipantCloseTest
> #
> RULE setup counter MultiParticipantCoordinatorCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> #####################################################################
> # Setup counter MultiServiceParticipantCompletionParticipantCloseTest
> #
> RULE setup counter MultiServiceParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> #####################################################################
> # Setup counter MultiServiceParticipantCompletionParticipantCloseAndExitTest
> #
> RULE setup counter MultiServiceParticipantCompletionParticipantCloseAndExitTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> {code}
> These can be re-factored in to a rule like this:
> {code}
> RULE setup counter
> INTERFACE org.jboss.jbossts.xts.servicetests.test.XTSServiceTest
> METHOD run()
> AT ENTRY
> IF $0.getClass().getName().contains("ParticipantCompletionParticipant")
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> {code}
> This assumes that we have the same numbers for each use of:
> {code}
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> {code}
> Which is *usually* the case:
> {code}
> grep -r createCounter\(\"closes\" .
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringOnePhaseCommit.txt: createCounter("closes", 1),
> ./src/test/resources/scripts/BASubordinateCrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BASubordinateCrashDuringComplete.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringOnePhaseCommit.txt: createCounter("closes", 1),
> ./target/test-classes/scripts/BASubordinateCrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BASubordinateCrashDuringComplete.txt: createCounter("closes", 3),
> {code}
> Maybe we just override the rule for the one exception. Ideas for what to do here are to be investigated.
> Also, the following similar rules are also present in this file:
> {code}
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseTest
> #
> RULE wait for closes MultiParticipantParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> #
> RULE wait for closes MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseTest
> #
> RULE wait for closes MultiServiceParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseAndExitTest
> #
> RULE wait for closes MultiServiceParticipantCompletionParticipantCloseAndExitTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> {code}
> Which could be replaced with something like this:
> {code}
> RULE wait for closes
> INTERFACE org.jboss.jbossts.xts.servicetests.test.XTSServiceTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF $0.getClass().getName().contains("ParticipantCompletionParticipant")
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> {code}
> We could also re-factor these two rules out into a separate Byteman script and add it to all tests that need it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (JBTM-1147) Refactor ParticipantCompletion recovery tests to remove duplicate rules
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1147?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1147:
--------------------------------
Description:
The Byteman rules for the participant completion XTS recovery tests have many rules that are almost duplicates of each other. For example:
The following rules in BACrashDuringCommit could be refactored into a single rule
{code}
#####################################################################
# Setup counter MultiParticipantParticipantCompletionParticipantCloseTest
#
RULE setup counter MultiParticipantParticipantCompletionParticipantCloseTest
CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseTest
METHOD run()
AT ENTRY
IF TRUE
DO debug("creating counter and rendezvous"),
createCounter("closes", 3),
createRendezvous("closes-complete", 2)
ENDRULE
#####################################################################
# Setup counter MultiParticipantCoordinatorCompletionParticipantCloseTest
#
RULE setup counter MultiParticipantCoordinatorCompletionParticipantCloseTest
CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseAndExitTest
METHOD run()
AT ENTRY
IF TRUE
DO debug("creating counter and rendezvous"),
createCounter("closes", 3),
createRendezvous("closes-complete", 2)
ENDRULE
#####################################################################
# Setup counter MultiServiceParticipantCompletionParticipantCloseTest
#
RULE setup counter MultiServiceParticipantCompletionParticipantCloseTest
CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseTest
METHOD run()
AT ENTRY
IF TRUE
DO debug("creating counter and rendezvous"),
createCounter("closes", 3),
createRendezvous("closes-complete", 2)
ENDRULE
#####################################################################
# Setup counter MultiServiceParticipantCompletionParticipantCloseAndExitTest
#
RULE setup counter MultiServiceParticipantCompletionParticipantCloseAndExitTest
CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseAndExitTest
METHOD run()
AT ENTRY
IF TRUE
DO debug("creating counter and rendezvous"),
createCounter("closes", 3),
createRendezvous("closes-complete", 2)
ENDRULE
{code}
These can be re-factored in to a rule like this:
{code}
RULE setup counter
INTERFACE org.jboss.jbossts.xts.servicetests.test.XTSServiceTest
METHOD run()
AT ENTRY
IF $0.getClass().getName().contains("ParticipantCompletionParticipant")
DO debug("creating counter and rendezvous"),
createCounter("closes", 3),
createRendezvous("closes-complete", 2)
ENDRULE
{code}
This assumes that we have the same numbers for each use of:
{code}
createCounter("closes", 3),
createRendezvous("closes-complete", 2)
{code}
Which is *usually* the case:
{code}
grep -r createCounter\(\"closes\" .
./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
./src/test/resources/scripts/BACrashDuringOnePhaseCommit.txt: createCounter("closes", 1),
./src/test/resources/scripts/BASubordinateCrashDuringCommit.txt: createCounter("closes", 3),
./src/test/resources/scripts/BASubordinateCrashDuringComplete.txt: createCounter("closes", 3),
./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
./target/test-classes/scripts/BACrashDuringOnePhaseCommit.txt: createCounter("closes", 1),
./target/test-classes/scripts/BASubordinateCrashDuringCommit.txt: createCounter("closes", 3),
./target/test-classes/scripts/BASubordinateCrashDuringComplete.txt: createCounter("closes", 3),
{code}
Maybe we just override the rule for the one exception. Ideas for what to do here are to be investigated.
Also, the following similar rules are also present in this file:
{code}
#####################################################################
# Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseTest
#
RULE wait for closes MultiParticipantParticipantCompletionParticipantCloseTest
CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseTest
METHOD run()
AT CALL UserBusinessActivity.close()
IF TRUE
DO debug("waiting to call close"),
rendezvous("closes-complete"),
debug("rendezvous complete, calling close")
ENDRULE
#####################################################################
# Wait on Rendezvous before calling uba.close() on MultiParticipantParticipantCompletionParticipantCloseAndExitTest
#
RULE wait for closes MultiParticipantParticipantCompletionParticipantCloseAndExitTest
CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseAndExitTest
METHOD run()
AT CALL UserBusinessActivity.close()
IF TRUE
DO debug("waiting to call close"),
rendezvous("closes-complete"),
debug("rendezvous complete, calling close")
ENDRULE
#####################################################################
# Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseTest
#
RULE wait for closes MultiServiceParticipantCompletionParticipantCloseTest
CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseTest
METHOD run()
AT CALL UserBusinessActivity.close()
IF TRUE
DO debug("waiting to call close"),
rendezvous("closes-complete"),
debug("rendezvous complete, calling close")
ENDRULE
#####################################################################
# Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseAndExitTest
#
RULE wait for closes MultiServiceParticipantCompletionParticipantCloseAndExitTest
CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseAndExitTest
METHOD run()
AT CALL UserBusinessActivity.close()
IF TRUE
DO debug("waiting to call close"),
rendezvous("closes-complete"),
debug("rendezvous complete, calling close")
ENDRULE
{code}
Which could be replaced with something like this:
{code}
RULE wait for closes
INTERFACE org.jboss.jbossts.xts.servicetests.test.XTSServiceTest
METHOD run()
AT CALL UserBusinessActivity.close()
IF $0.getClass().getName().contains("ParticipantCompletionParticipant")
DO debug("waiting to call close"),
rendezvous("closes-complete"),
debug("rendezvous complete, calling close")
ENDRULE
{code}
We could also re-factor these two rules out into a separate Byteman script and add it to all tests that need it.
was:
The Byteman rules for the participant completion XTS recovery tests have many rules that are almost duplicates of each other. For example:
The following rules in BACrashDuringCommit could be refactored into a single rule
{code}
#####################################################################
# Setup counter MultiParticipantParticipantCompletionParticipantCloseTest
#
RULE setup counter MultiParticipantParticipantCompletionParticipantCloseTest
CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseTest
METHOD run()
AT ENTRY
IF TRUE
DO debug("creating counter and rendezvous"),
createCounter("closes", 3),
createRendezvous("closes-complete", 2)
ENDRULE
#####################################################################
# Setup counter MultiParticipantCoordinatorCompletionParticipantCloseTest
#
RULE setup counter MultiParticipantCoordinatorCompletionParticipantCloseTest
CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseAndExitTest
METHOD run()
AT ENTRY
IF TRUE
DO debug("creating counter and rendezvous"),
createCounter("closes", 3),
createRendezvous("closes-complete", 2)
ENDRULE
#####################################################################
# Setup counter MultiServiceParticipantCompletionParticipantCloseTest
#
RULE setup counter MultiServiceParticipantCompletionParticipantCloseTest
CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseTest
METHOD run()
AT ENTRY
IF TRUE
DO debug("creating counter and rendezvous"),
createCounter("closes", 3),
createRendezvous("closes-complete", 2)
ENDRULE
#####################################################################
# Setup counter MultiServiceParticipantCompletionParticipantCloseAndExitTest
#
RULE setup counter MultiServiceParticipantCompletionParticipantCloseAndExitTest
CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseAndExitTest
METHOD run()
AT ENTRY
IF TRUE
DO debug("creating counter and rendezvous"),
createCounter("closes", 3),
createRendezvous("closes-complete", 2)
ENDRULE
{code}
These can be re-factored in to a rule like this:
{code}
RULE setup counter
INTERFACE org.jboss.jbossts.xts.servicetests.test.XTSServiceTest
METHOD run()
AT ENTRY
IF $0.getClass().getName().contains("ParticipantCompletionParticipant")
DO debug("creating counter and rendezvous"),
createCounter("closes", 3),
createRendezvous("closes-complete", 2)
ENDRULE
{code}
Also, the following similar rules are also present in this file:
{code}
#####################################################################
# Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseTest
#
RULE wait for closes MultiParticipantParticipantCompletionParticipantCloseTest
CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseTest
METHOD run()
AT CALL UserBusinessActivity.close()
IF TRUE
DO debug("waiting to call close"),
rendezvous("closes-complete"),
debug("rendezvous complete, calling close")
ENDRULE
#####################################################################
# Wait on Rendezvous before calling uba.close() on MultiParticipantParticipantCompletionParticipantCloseAndExitTest
#
RULE wait for closes MultiParticipantParticipantCompletionParticipantCloseAndExitTest
CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseAndExitTest
METHOD run()
AT CALL UserBusinessActivity.close()
IF TRUE
DO debug("waiting to call close"),
rendezvous("closes-complete"),
debug("rendezvous complete, calling close")
ENDRULE
#####################################################################
# Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseTest
#
RULE wait for closes MultiServiceParticipantCompletionParticipantCloseTest
CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseTest
METHOD run()
AT CALL UserBusinessActivity.close()
IF TRUE
DO debug("waiting to call close"),
rendezvous("closes-complete"),
debug("rendezvous complete, calling close")
ENDRULE
#####################################################################
# Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseAndExitTest
#
RULE wait for closes MultiServiceParticipantCompletionParticipantCloseAndExitTest
CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseAndExitTest
METHOD run()
AT CALL UserBusinessActivity.close()
IF TRUE
DO debug("waiting to call close"),
rendezvous("closes-complete"),
debug("rendezvous complete, calling close")
ENDRULE
{code}
Which could be replaced with something like this:
{code}
RULE wait for closes
INTERFACE org.jboss.jbossts.xts.servicetests.test.XTSServiceTest
METHOD run()
AT CALL UserBusinessActivity.close()
IF $0.getClass().getName().contains("ParticipantCompletionParticipant")
DO debug("waiting to call close"),
rendezvous("closes-complete"),
debug("rendezvous complete, calling close")
ENDRULE
{code}
We could also re-factor these two rules out into a separate Byteman script and add it to all tests that need it.
> Refactor ParticipantCompletion recovery tests to remove duplicate rules
> -----------------------------------------------------------------------
>
> Key: JBTM-1147
> URL: https://issues.jboss.org/browse/JBTM-1147
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: XTS
> Affects Versions: 4.16.4, 5.0.0.M1
> Reporter: Paul Robinson
> Assignee: Amos Feng
> Priority: Minor
> Fix For: 5.0.0.Final
>
>
> The Byteman rules for the participant completion XTS recovery tests have many rules that are almost duplicates of each other. For example:
> The following rules in BACrashDuringCommit could be refactored into a single rule
> {code}
> #####################################################################
> # Setup counter MultiParticipantParticipantCompletionParticipantCloseTest
> #
> RULE setup counter MultiParticipantParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> #####################################################################
> # Setup counter MultiParticipantCoordinatorCompletionParticipantCloseTest
> #
> RULE setup counter MultiParticipantCoordinatorCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> #####################################################################
> # Setup counter MultiServiceParticipantCompletionParticipantCloseTest
> #
> RULE setup counter MultiServiceParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> #####################################################################
> # Setup counter MultiServiceParticipantCompletionParticipantCloseAndExitTest
> #
> RULE setup counter MultiServiceParticipantCompletionParticipantCloseAndExitTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT ENTRY
> IF TRUE
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> {code}
> These can be re-factored in to a rule like this:
> {code}
> RULE setup counter
> INTERFACE org.jboss.jbossts.xts.servicetests.test.XTSServiceTest
> METHOD run()
> AT ENTRY
> IF $0.getClass().getName().contains("ParticipantCompletionParticipant")
> DO debug("creating counter and rendezvous"),
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> ENDRULE
> {code}
> This assumes that we have the same numbers for each use of:
> {code}
> createCounter("closes", 3),
> createRendezvous("closes-complete", 2)
> {code}
> Which is *usually* the case:
> {code}
> grep -r createCounter\(\"closes\" .
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BACrashDuringOnePhaseCommit.txt: createCounter("closes", 1),
> ./src/test/resources/scripts/BASubordinateCrashDuringCommit.txt: createCounter("closes", 3),
> ./src/test/resources/scripts/BASubordinateCrashDuringComplete.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BACrashDuringOnePhaseCommit.txt: createCounter("closes", 1),
> ./target/test-classes/scripts/BASubordinateCrashDuringCommit.txt: createCounter("closes", 3),
> ./target/test-classes/scripts/BASubordinateCrashDuringComplete.txt: createCounter("closes", 3),
> {code}
> Maybe we just override the rule for the one exception. Ideas for what to do here are to be investigated.
> Also, the following similar rules are also present in this file:
> {code}
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseTest
> #
> RULE wait for closes MultiParticipantParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> #
> RULE wait for closes MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiParticipantParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseTest
> #
> RULE wait for closes MultiServiceParticipantCompletionParticipantCloseTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> #####################################################################
> # Wait on Rendezvous before calling uba.close() on MultiServiceParticipantCompletionParticipantCloseAndExitTest
> #
> RULE wait for closes MultiServiceParticipantCompletionParticipantCloseAndExitTest
> CLASS org.jboss.jbossts.xts.servicetests.test.ba.MultiServiceParticipantCompletionParticipantCloseAndExitTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF TRUE
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> {code}
> Which could be replaced with something like this:
> {code}
> RULE wait for closes
> INTERFACE org.jboss.jbossts.xts.servicetests.test.XTSServiceTest
> METHOD run()
> AT CALL UserBusinessActivity.close()
> IF $0.getClass().getName().contains("ParticipantCompletionParticipant")
> DO debug("waiting to call close"),
> rendezvous("closes-complete"),
> debug("rendezvous complete, calling close")
> ENDRULE
> {code}
> We could also re-factor these two rules out into a separate Byteman script and add it to all tests that need it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (JBTM-1016) Run bmcheck.sh regularly to spot inconsistencies between byteman scripts and the code
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1016?page=com.atlassian.jira.plugin.... ]
Paul Robinson updated JBTM-1016:
--------------------------------
Labels: assign (was: )
> Run bmcheck.sh regularly to spot inconsistencies between byteman scripts and the code
> -------------------------------------------------------------------------------------
>
> Key: JBTM-1016
> URL: https://issues.jboss.org/browse/JBTM-1016
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: XTS
> Reporter: Paul Robinson
> Assignee: Amos Feng
> Labels: assign
> Fix For: 5.0.0.Final
>
>
> I've found many bugs in the XTS crash recovery tests that where due to changes being made to the XTS code without updating the byteman scripts. The problem is that these inconsistencies often go unnoticed when the tests run, until you notice a failure in the test.
> Can we run bmcheck as part of the maven build and make the build fail if it detects errors? Needs to be integrated into the poms, perhaps by an exec in an antrun plugin
> NOTE: Before raising the pull req it will be necessary to resolve any the discovered errors.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (JBTM-1116) Document configuration
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1116?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1116:
--------------------------------
Fix Version/s: 5.0.0.M2
(was: 5.0.0.M3)
> Document configuration
> ----------------------
>
> Key: JBTM-1116
> URL: https://issues.jboss.org/browse/JBTM-1116
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Documentation
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Priority: Minor
> Fix For: 5.0.0.M2
>
>
> In the pre-Bean days of setting properties, we had all of the TS properties called out in a properties.xml file. In that file there were copious comments to say what the property was for and whether it should be changed. We also documented these properties in the docs. It seems from some investigation that Mike and I have done today that the migration away from the properties file to using MBeans has removed those comments and the docs for the properties. Sometimes the comments do appear in the code.
> If you go back to before everything got turned everything into a Bean (probably 4.6.1 GA) then look in the etc directories.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] (JBTM-1155) Remember where we are in the commit list for recovery
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1155?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson resolved JBTM-1155.
---------------------------------
Resolution: Done
> Remember where we are in the commit list for recovery
> -----------------------------------------------------
>
> Key: JBTM-1155
> URL: https://issues.jboss.org/browse/JBTM-1155
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Recovery, Transaction Core
> Affects Versions: 4.16.4
> Reporter: Mark Little
> Assignee: Mark Little
> Fix For: 5.0.0.M2
>
>
> We keep track of where the coordinator is in the list of resources to commit during doCommit, so that we can avoid heuristics as much as possible. Basically we need to remember if we have gotten past the first participant. However, we do not remember this value (boolean) as part of the transaction state. This means that upon recovery there is a chance that a participant that failed to commit the first time round and then causes a heuristic rollback subsequently, will cause the transaction silently mask the heuristic and roll back all of the other participants, delete the log and report a normal transaction abort state. In fact it should ensure the heuristic is raised.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months