[JBoss JIRA] (JBTM-2069) Review BlackTie docs
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2069?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2069:
--------------------------------
Fix Version/s: 5.0.4
(was: 6.0.0)
> Review BlackTie docs
> --------------------
>
> Key: JBTM-2069
> URL: https://issues.jboss.org/browse/JBTM-2069
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: BlackTie, Documentation
> Reporter: Tom Jenkinson
> Assignee: Amos Feng
> Fix For: 5.0.4
>
>
> Ensure no erroneous information
> Update AS7 references to WildFly
> For example:
> run.sh -> standalone.sh (changed parameters too)
> JBossAS->WildFly
> paths, are they up-to-date (for example what apps should be deployed and where)
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months
[JBoss JIRA] (JBTM-1586) reloadDomain reloadServer: reload configuration server operation (compatable with svn update)
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1586?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson closed JBTM-1586.
-------------------------------
Resolution: Won't Fix
Will focus community effort on the java container linked
> reloadDomain reloadServer: reload configuration server operation (compatable with svn update)
> ---------------------------------------------------------------------------------------------
>
> Key: JBTM-1586
> URL: https://issues.jboss.org/browse/JBTM-1586
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Components: BlackTie
> Reporter: Tom Jenkinson
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> reloadDomain: This method is available from the "control" tab of a domain and operates on all servers
> reloadServer:
> it would be useful to have a reload server configuration operation.
> this will require an external shell script to repeatedly start server.exe processes dependent upon exit status of server.exe
> the serverdone operation can then be altered to return a specific return code dependent upon whether shutdown/reload configuration was issued.
> The use of this method is if the environment.xml file has changed the server can be rebooted with the new configuration file
> the shell script would look like (we would need one for windows and one for linux):
> int startServer = 1;
> while (startServer)
> int exitStatus = server.exe();
> if (exitStatus == reloadConfiguration) {
> startServer = 1;
> svn update configuration;
> } else {
> startServer = 0;
> }
> NOTE: This method does not take an id parameter as all servers must be reloaded
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months
[JBoss JIRA] (JBTM-1147) Refactor ParticipantCompletion recovery tests to remove duplicate rules
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1147?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson resolved JBTM-1147.
---------------------------------
Fix Version/s: (was: 6.0.0)
Resolution: Deferred
As the issue is stalled and there is no direct benefit to this beyond general maintenance I am deferring this. It can be reopened should our community be interested in the code challenge of byteman gymnastics.
> 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
> Components: XTS
> Affects Versions: 4.16.4, 4.17.0.M1/5.0.0.M1
> Reporter: Paul Robinson
> Priority: Minor
>
> 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 was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months
[JBoss JIRA] (JBTM-2287) JTS recovery module forgets about transaction -> transaction never recovered
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2287?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2287:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Double end fixed in linked PR
> JTS recovery module forgets about transaction -> transaction never recovered
> ----------------------------------------------------------------------------
>
> Key: JBTM-2287
> URL: https://issues.jboss.org/browse/JBTM-2287
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Affects Versions: 4.17.15
> Environment: EAP 6.2.4 with JBoss Transactions 4.17.15
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
>
> The scenario is as follows (and works fine with JTA, see below):
> Two XAResources in the same transaction, with xid1 and xid2, respectively.
> (For better readability, log file excerpts are referenced and provided at the end of the description.)
> start xid1
> start xid2
> end xid1, tmsuccess
> prepare xid1 -> XAException.XAER_RMFAIL; provoked, txn is indeed prepared in our test case
> end xid1, tmfail -> against XA protocol, however silently ignored by us
> [error1 printed in log file]
> end xid2, tmfail
> rollback xid2
> [error2 printed in log file]
> [JTS: periodic, but fruitless recovery attempts]
> as an effect, the transaction branch is never recovered and the dead transaction hangs around forever in the database; it looks like, as if the JTS recovery component forgot to early about that transaction, so does not do any rollback/commit decision for the reported to-be-recovered transaction
> with JTA the call sequence is as follows:
> start xid1
> start xid2
> end xid1, tmsuccess
> prepare xid1 -> XAException.XAER_RMFAIL; provoked, txn is indeed prepared in our test case
> rollback xid1 //this races with recovery module, but in any case, will be rolled back
> end xid2, tmfail
> rollback xid2
> [JTA: periodic, successfull recovery]
> With JTA, rollback might even be triggered twice (second invocation ignored by us)
> here the log file excerpts, Xids printed with own toString() impl, because of JBTM-2284)
> [JTA: periodic, successfull recovery]
> 10:48:20,646 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 10:48:20,646 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131077-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.113.21.-21.110.84.100.126.76.0.0.0.41.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.113.21.-21.110.84.100.126.76.0.0.0.42.0.0.0.0.0.0.0.0
> 10:48:23,689 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Rolled back xid < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff0a6a3229:7115eb6e:54647e4c:29, node_name=1, branch_uid=0:ffff0a6a3229:7115eb6e:54647e4c:2a, subordinatenodename=null, eis_name=unknown eis name >
> [JTS: periodic, but fruitless recovery attempts]
> 09:59:49,664 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 09:59:49,665 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131072-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.70.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.72.0.0.0.0.0.0.0.0
> 09:59:58,022 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 09:59:58,022 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131072-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.70.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.72.0.0.0.0.0.0.0.0
> 10:00:06,067 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 10:00:06,067 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131072-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.70.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.72.0.0.0.0.0.0.0.0
> 10:00:14,184 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 10:00:14,184 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131072-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.70.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.72.0.0.0.0.0.0.0.0
> 10:00:22,275 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 10:00:22,275 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131072-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.70.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.72.0.0.0.0.0.0.0.0
> 10:00:30,329 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 10:00:30,329 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131072-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.70.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.72.0.0.0.0.0.0.0.0
> 10:00:38,377 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 10:00:38,377 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131072-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.70.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.72.0.0.0.0.0.0.0.0
> 10:00:46,493 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 10:00:46,493 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131072-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.70.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.72.0.0.0.0.0.0.0.0
> 10:00:54,545 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Found 1 XA transactions to recover.
> 10:00:54,545 INFO [com.versant.odbms.XARecoveryResource] (Periodic Recovery) Versant JPA: Xid to recover: 131072-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.70.49-0.0.0.0.0.0.0.0.0.0.-1.-1.10.106.50.41.-50.-61.50.100.84.100.114.-11.0.0.0.72.0.0.0.0.0.0.0.0
> [error1]
> 09:59:46,904 WARN [com.arjuna.ats.jts] (EJB default - 4) ARJUNA022223: ExtendedResourceRecord.topLevelAbort caught exception: org.omg.CORBA.UNKNOWN: Server-side Exception: null
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [rt.jar:1.7.0_25]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) [rt.jar:1.7.0_25]
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) [rt.jar:1.7.0_25]
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526) [rt.jar:1.7.0_25]
> at org.jacorb.orb.SystemExceptionHelper.read(SystemExceptionHelper.java:223) [jacorb-2.3.2.redhat-6.jar:2.3.2.redhat-6]
> at org.jacorb.orb.ReplyReceiver.getReply(ReplyReceiver.java:319) [jacorb-2.3.2.redhat-6.jar:2.3.2.redhat-6]
> at org.jacorb.orb.Delegate.invoke_internal(Delegate.java:1090) [jacorb-2.3.2.redhat-6.jar:2.3.2.redhat-6]
> at org.jacorb.orb.Delegate.invoke(Delegate.java:957) [jacorb-2.3.2.redhat-6.jar:2.3.2.redhat-6]
> at org.omg.CORBA.portable.ObjectImpl._invoke(ObjectImpl.java:80) [jacorb-2.3.2.redhat-6.jar:2.3.2.redhat-6]
> at com.arjuna.ArjunaOTS._ArjunaSubtranAwareResourceStub.rollback(_ArjunaSubtranAwareResourceStub.java:75)
> at com.arjuna.ats.internal.jts.resources.ExtendedResourceRecord.topLevelAbort(ExtendedResourceRecord.java:445)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2875)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2854)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1924)
> at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1494)
> at com.arjuna.ats.internal.jts.orbspecific.coordinator.ArjunaTransactionImple.commit(ArjunaTransactionImple.java:375)
> at com.arjuna.ats.internal.jts.ControlWrapper.commit(ControlWrapper.java:243)
> at com.arjuna.ats.internal.jts.orbspecific.CurrentImple.commit(CurrentImple.java:247)
> at com.arjuna.ats.jts.extensions.AtomicTransaction.commit(AtomicTransaction.java:276)
> at com.arjuna.ats.internal.jta.transaction.jts.TransactionImple.commitAndDisassociate(TransactionImple.java:1296)
> at com.arjuna.ats.internal.jta.transaction.jts.BaseTransaction.commit(BaseTransaction.java:130)
> at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) [jboss-as-ejb3-7.3.4.Final-redhat-1.jar:7.3.4.Final-redhat-1]
>
> [error2]
> 09:59:46,962 ERROR [stderr] (EJB default - 4) org.omg.CORBA.TRANSACTION_ROLLEDBACK
> 09:59:46,962 ERROR [stderr] (EJB default - 4) at com.arjuna.ats.internal.jts.orbspecific.coordinator.ArjunaTransactionImple.commit(ArjunaTransactionImple.java:414)
> 09:59:46,963 ERROR [stderr] (EJB default - 4) at com.arjuna.ats.internal.jts.ControlWrapper.commit(ControlWrapper.java:243)
> 09:59:46,963 ERROR [stderr] (EJB default - 4) at com.arjuna.ats.internal.jts.orbspecific.CurrentImple.commit(CurrentImple.java:247)
> 09:59:46,963 ERROR [stderr] (EJB default - 4) at com.arjuna.ats.jts.extensions.AtomicTransaction.commit(AtomicTransaction.java:276)
> 09:59:46,963 ERROR [stderr] (EJB default - 4) at com.arjuna.ats.internal.jta.transaction.jts.TransactionImple.commitAndDisassociate(TransactionImple.java:1296)
> 09:59:46,963 ERROR [stderr] (EJB default - 4) at com.arjuna.ats.internal.jta.transaction.jts.BaseTransaction.commit(BaseTransaction.java:130)
> 09:59:46,964 ERROR [stderr] (EJB default - 4) at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
> 09:59:46,964 ERROR [stderr] (EJB default - 4) at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92)
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months
[JBoss JIRA] (JBTM-2289) TransactionalDriver QA_JTA tests fail on Oracle
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2289?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2289:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> TransactionalDriver QA_JTA tests fail on Oracle
> -----------------------------------------------
>
> Key: JBTM-2289
> URL: https://issues.jboss.org/browse/JBTM-2289
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA, Testing
> Reporter: Gytis Trikleris
> Assignee: Tom Jenkinson
> Priority: Blocker
> Fix For: 5.0.4
>
>
> http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/685/PROFIL...
> {code}
> BUILD FAILED
> /home/hudson/workspace/narayana/PROFILE/QA_JTA/jdk/jdk7.latest/label/linux/qa/run-tests.xml:111: some tests failed
> Total time: 148 minutes 16 seconds
> Test Failures:
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test019 Fail (2m52.176s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test020 Fail (1m48.440s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test021 Fail (2m51.868s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test022 Fail (1m48.429s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test029 Fail (2m56.246s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test030 Fail (1m48.966s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test031 Fail (2m56.454s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test032 Fail (1m49.092s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test008 Fail (2m47.491s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test009 Fail (1m48.420s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test010 Fail (2m45.377s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test011 Fail (1m49.096s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test012 Fail (2m48.005s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test013 Fail (1m48.328s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test019 Fail (2m51.740s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test020 Fail (1m48.531s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test021 Fail (2m51.655s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test022 Fail (1m48.485s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test029 Fail (2m56.792s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test030 Fail (1m48.883s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test031 Fail (2m56.524s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test032 Fail (1m48.943s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test008 Fail (2m45.500s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test009 Fail (1m48.318s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test010 Fail (2m47.985s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test011 Fail (1m48.492s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test012 Fail (2m45.681s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test013 Fail (1m48.303s)
> Buildfile: /home/hudson/workspace/narayana/PROFILE/QA_JTA/jdk/jdk7.latest/label/linux/qa/run-tests.xml
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months
[JBoss JIRA] (JBTM-2289) TransactionalDriver QA_JTA tests fail on Oracle
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2289?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2289:
--------------------------------
Summary: TransactionalDriver QA_JTA tests fail on Oracle (was: All QA_JTA tests fail on Oracle)
> TransactionalDriver QA_JTA tests fail on Oracle
> -----------------------------------------------
>
> Key: JBTM-2289
> URL: https://issues.jboss.org/browse/JBTM-2289
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA, Testing
> Reporter: Gytis Trikleris
> Assignee: Tom Jenkinson
> Priority: Blocker
> Fix For: 5.0.4
>
>
> http://albany.eng.hst.ams2.redhat.com/view/Status/job/narayana/685/PROFIL...
> {code}
> BUILD FAILED
> /home/hudson/workspace/narayana/PROFILE/QA_JTA/jdk/jdk7.latest/label/linux/qa/run-tests.xml:111: some tests failed
> Total time: 148 minutes 16 seconds
> Test Failures:
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test019 Fail (2m52.176s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test020 Fail (1m48.440s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test021 Fail (2m51.868s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test022 Fail (1m48.429s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test029 Fail (2m56.246s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test030 Fail (1m48.966s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test031 Fail (2m56.454s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test032 Fail (1m49.092s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test008 Fail (2m47.491s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test009 Fail (1m48.420s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test010 Fail (2m45.377s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test011 Fail (1m49.096s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test012 Fail (2m48.005s)
> jdbcresources01_oracle_thin_jndi JDBCResources01_abstract_Test013 Fail (1m48.328s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test019 Fail (2m51.740s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test020 Fail (1m48.531s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test021 Fail (2m51.655s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test022 Fail (1m48.485s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test029 Fail (2m56.792s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test030 Fail (1m48.883s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test031 Fail (2m56.524s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test032 Fail (1m48.943s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test008 Fail (2m45.500s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test009 Fail (1m48.318s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test010 Fail (2m47.985s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test011 Fail (1m48.492s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test012 Fail (2m45.681s)
> jdbcresources02_oracle_thin_jndi JDBCResources02_abstract_Test013 Fail (1m48.303s)
> Buildfile: /home/hudson/workspace/narayana/PROFILE/QA_JTA/jdk/jdk7.latest/label/linux/qa/run-tests.xml
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
9 years, 6 months