[JBoss JIRA] (JBTM-1735) Support volatile store in StateManager
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1735?page=com.atlassian.jira.plugin.... ]
Mark Little closed JBTM-1735.
-----------------------------
> Support volatile store in StateManager
> --------------------------------------
>
> Key: JBTM-1735
> URL: https://issues.jboss.org/browse/JBTM-1735
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: STM, Transaction Core
> Affects Versions: 5.0.0.M3
> Reporter: Mark Little
> Assignee: Mark Little
> Fix For: 5.0.0.M4
>
>
> Comment in StateManager from *years* ago:
> /*
> * Currently we should never get here! However, since Arjuna
> * supports a volatile (in memory) object store we will also
> * eventually, probably through a set of native methods.
> */
> We've had volatile (in memory) support for quite a while. Used for testing purposed currently, but also now for STM.
--
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
10 years, 11 months
[JBoss JIRA] (JBTM-1735) Support volatile store in StateManager
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1735?page=com.atlassian.jira.plugin.... ]
Mark Little resolved JBTM-1735.
-------------------------------
Resolution: Done
> Support volatile store in StateManager
> --------------------------------------
>
> Key: JBTM-1735
> URL: https://issues.jboss.org/browse/JBTM-1735
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: STM, Transaction Core
> Affects Versions: 5.0.0.M3
> Reporter: Mark Little
> Assignee: Mark Little
> Fix For: 5.0.0.M4
>
>
> Comment in StateManager from *years* ago:
> /*
> * Currently we should never get here! However, since Arjuna
> * supports a volatile (in memory) object store we will also
> * eventually, probably through a set of native methods.
> */
> We've had volatile (in memory) support for quite a while. Used for testing purposed currently, but also now for STM.
--
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
10 years, 11 months
[JBoss JIRA] (JBTM-1735) Support volatile store in StateManager
by Mark Little (JIRA)
Mark Little created JBTM-1735:
---------------------------------
Summary: Support volatile store in StateManager
Key: JBTM-1735
URL: https://issues.jboss.org/browse/JBTM-1735
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: STM, Transaction Core
Affects Versions: 5.0.0.M3
Reporter: Mark Little
Assignee: Mark Little
Fix For: 5.0.0.M4
Comment in StateManager from *years* ago:
/*
* Currently we should never get here! However, since Arjuna
* supports a volatile (in memory) object store we will also
* eventually, probably through a set of native methods.
*/
We've had volatile (in memory) support for quite a while. Used for testing purposed currently, but also now for STM.
--
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
10 years, 11 months
[JBoss JIRA] (JBTM-1147) Refactor ParticipantCompletion recovery tests to remove duplicate rules
by Ondřej Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-1147?page=com.atlassian.jira.plugin.... ]
Ondřej Chaloupka commented on JBTM-1147:
----------------------------------------
I went through the rules I didn't find any other good adept for refactoring/reducing except of the rule mentioned in the description. I've found to have problem with usage of INTERFACE in the rule so I've changed it for using upper class. There is my change here:
https://github.com/ochaloup/narayana/commit/c81c125a0f44c0edf79b7d4d8c42a...
Then there are two rules "RULE open trace file" and "RULE reset periodic recovery wait time" staying in all the files. Those could be extracted to some common file used by all tests. But I think that it would degrade readability.
I checked just the syntax of the rules. I supposed that all of them have some purpose in the set. I haven't tried to deeply investigate whether some of them are not useful for the logic of the tests anymore.
We agreed with Paul that this would be more difficult than what I understand to be the object of the issue. There would be probably needed some input from Andrew Dinn.
Currently this issue is not critical and will be defered till the time that there will be need to work with the scripts.
> 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: Task
> Security Level: Public(Everyone can see)
> Components: XTS
> Affects Versions: 4.16.4, 5.0.0.M1
> Reporter: Paul Robinson
> Assignee: Ondřej Chaloupka
> Priority: Minor
> Fix For: 5.0.0.M4
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> 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
10 years, 11 months
[JBoss JIRA] (JBTM-1734) RTS subsystem compilation errors with AbstractRTSService.java
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1734?page=com.atlassian.jira.plugin.... ]
Gytis Trikleris updated JBTM-1734:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/jboss-as/pull/10
> RTS subsystem compilation errors with AbstractRTSService.java
> -------------------------------------------------------------
>
> Key: JBTM-1734
> URL: https://issues.jboss.org/browse/JBTM-1734
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Application Server Integration
> Reporter: Amos Feng
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M4
>
>
> http://172.17.131.2/view/Narayana+BlackTie/job/narayana/79/TESTS=MAIN,jdk...
> {noformat}
> [ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR] /home/hudson/workspace/narayana/TESTS/MAIN/jdk/jdk7.latest/label/linux/jboss-as/rts/src/main/java/org/wildfly/extension/rts/service/AbstractRTSService.java:[56,36] method registerDeployment in class org.wildfly.extension.undertow.Host cannot be applied to given types;
> required: io.undertow.servlet.api.Deployment,io.undertow.server.HttpHandler
> found: io.undertow.servlet.api.DeploymentInfo,io.undertow.server.HttpHandler
> reason: actual argument io.undertow.servlet.api.DeploymentInfo cannot be converted to io.undertow.servlet.api.Deployment by method invocation conversion
> [ERROR] /home/hudson/workspace/narayana/TESTS/MAIN/jdk/jdk7.latest/label/linux/jboss-as/rts/src/main/java/org/wildfly/extension/rts/service/AbstractRTSService.java:[64,36] method unregisterDeployment in class org.wildfly.extension.undertow.Host cannot be applied to given types;
> required: io.undertow.servlet.api.Deployment
> found: io.undertow.servlet.api.DeploymentInfo
> reason: actual argument io.undertow.servlet.api.DeploymentInfo cannot be converted to io.undertow.servlet.api.Deployment by method invocation conversion
> {noformat}
--
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
10 years, 11 months
[JBoss JIRA] (JBTM-1635) Enhance TRACE for delistResource
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBTM-1635?page=com.atlassian.jira.plugin.... ]
Jesper Pedersen commented on JBTM-1635:
---------------------------------------
Hi Tom, yeah, there is no OR - so either the int or the string value would be perfect
> Enhance TRACE for delistResource
> --------------------------------
>
> Key: JBTM-1635
> URL: https://issues.jboss.org/browse/JBTM-1635
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 4.17.3
> Reporter: Jesper Pedersen
> Assignee: Tom Jenkinson
> Priority: Minor
> Fix For: 5.0.0.M4
>
>
> The following
> {noformat}
> TRACE [com.arjuna.ats.jta] (MSC service thread 1-14) TransactionImple.delistResource
> {noformat}
> statement would benefit for logging the actual TM flag sent
--
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
10 years, 11 months
[JBoss JIRA] (JBTM-1669) Remove tanukisoftware wrapper dependency from EAP6 profile
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1669?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-1669:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/narayana/pull/324
> Remove tanukisoftware wrapper dependency from EAP6 profile
> ----------------------------------------------------------
>
> Key: JBTM-1669
> URL: https://issues.jboss.org/browse/JBTM-1669
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Build System
> Affects Versions: 4.17.4
> Reporter: Weinan Li
> Assignee: Tom Jenkinson
>
> Currently we have tanuki in these components:
> {code}
> ArjunaCore/arjuna/services/pom.xml
> ArjunaJTS/narayana-jts-idlj/pom.xml
> ArjunaJTS/narayana-jts-jacorb/pom.xml
> pom.xml
> {code}
> {code}
> <dependency>
> <groupId>tanukisoft</groupId>
> <artifactId>wrapper</artifactId>
> <version>${version.tanukisoft}</version>
> </dependency>
> {code}
> We need to remove these dependencies from eap6 profile according to comments from Fernando:
> {quote}
> We do not ship tanukiwrapper with the AS (the windows on is an exceptional case and for different reasons).
> It is not in the AS7 dependencies, and it will be hard for Support to
> properly rebuild TS in the field.
> {quote}
> btw, there are two classes we need to remove from eap6 profile which depends on tanuki wrapper:
> {code}
> ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/services/recovery/RecoveryManagerService.java
> ArjunaJTS/jts/services/classes/com/arjuna/ats/jts/services/transactionserver/TransactionServerService.java
> {code}
--
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
10 years, 11 months