[JBoss JIRA] (JBTM-312) Add clustering support
by Andrig Miller (JIRA)
[ https://issues.jboss.org/browse/JBTM-312?page=com.atlassian.jira.plugin.s... ]
Andrig Miller commented on JBTM-312:
------------------------------------
I might be worth investigating the active/backup model from HornetQ. You could use the journal file on a clustered file system (GFS2 and NFS are supported - NFS is only supported under very specific configuration guidelines), and use the same file locking semantics between the active and backup pair (multiple backups are supported too), and then there is no need to use a slow object store, with communication channels for the fail over. There is reduced complexity, no HA requirement on the database, and no need to something to watch each node.
> Add clustering support
> ----------------------
>
> Key: JBTM-312
> URL: https://issues.jboss.org/browse/JBTM-312
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: JTA, JTS, Recovery, Transaction Core, XTS
> Affects Versions: 4.3.0.BETA2
> Reporter: Mark Little
> Assignee: Tom Jenkinson
> Fix For: 4.17.4, 5.0.0.M3
>
>
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-1433) Strange XA recovery behaviour - after sucessful commit is recovery called second
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1433?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1433:
-------------------------------------
Hi Ondra,
Did you note my point above how it would probably be more useful to test this against the version going into EAP 6.1, i.e. the 4.17 branch (it isn't much different to master but I guess you will have to test this anyway so maybe it makes sense to start there).
I am able to run the test now so hopefully I should have more info for you shortly!
Tom
> Strange XA recovery behaviour - after sucessful commit is recovery called second
> --------------------------------------------------------------------------------
>
> Key: JBTM-1433
> URL: https://issues.jboss.org/browse/JBTM-1433
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.0.0.M2
> Reporter: Ondřej Chaloupka
> Assignee: Tom Jenkinson
> Fix For: 4.17.4, 5.0.0.M2
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Hi,
> I've hit problem for functionality of XA recovery. This was found because of CI job running against master (http://hudson.qa.jboss.com/hudson/job/jbossts-crashrec-tests-postgresql91...)
> After change of TM for the 5.0.0.M2 this started to occur.
> This problem is not just for postgresql but on all DBs tested by CI runs (oracle, db2.97, sybase).
> *What is tested and what's happening*
> Test halts server at commit phase (used byteman) before commit is done.
> The test enlists the resource of DB to transaction and then it enlists one XA resource created just for testing purposes for us having 2 participants in the transaction.
> After some debugging I think (but I'm not sure) that when server starts after halt the recovery runs fine. Commit is provided (or at least the DB record is updated sucessfully). But after that narayana tries to run some second round of recovery and in spite of the fact that the transaction was successfully committed (and it seems to be deleted from object store) it tries to do recovery on this transaction once more and the resource manager returns exception because it does not know that id already.
> I think that the problem is starting with message:
> {code}
> 15:25:28,570 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016008: Local XARecoveryModule.xaRecovery - caught exception: java.lang.NullPointerException
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:598) [narayana-jts-jacorb-5.0.0.M2-SNAPSHOT.jar:5.0.0.M2-SNAPSHOT (revision: 1fa9d41e685713c7323222a0bb83e41ec1fd3d31)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:413) [narayana-jts-jacorb-5.0.0.M2-SNAPSHOT.jar:5.0.0.M2-SNAPSHOT (revision: 1fa9d41e685713c7323222a0bb83e41ec1fd3d31)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:193) [narayana-jts-jacorb-5.0.0.M2-SNAPSHOT.jar:5.0.0.M2-SNAPSHOT (revision: 1fa9d41e685713c7323222a0bb83e41ec1fd3d31)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.0.M2-SNAPSHOT.jar:5.0.0.M2-SNAPSHOT (revision: 1fa9d41e685713c7323222a0bb83e41ec1fd3d31)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.M2-SNAPSHOT.jar:5.0.0.M2-SNAPSHOT (revision: 1fa9d41e685713c7323222a0bb83e41ec1fd3d31)]
> {code}
> More from log:
> {code}
> 15:25:28,386 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) BasicAction::doCommit (XAResourceRecord < resource:XAResourceWrapperImpl@11455a2[xaResource=org.jboss.jca.adapters.jdbc.xa.XAManagedConnection@212b9 pad=false overrideRmValue=null productName=PostgreSQL productVersion=9.1.4 jndiName=java:jboss/xa-datasources/VerificationDS], txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:3d6777ab:50f804c8:2b, node_name=1, branch_uid=0:ffff7f000001:3d6777ab:50f804c8:34, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS >, heuristic: TwoPhaseOutcome.FINISH_OK, product: PostgreSQL/9.1.4, jndiName: java:jboss/xa-datasources/CrashRecoveryDS com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@13c2797 >)
> 15:25:28,386 TRACE [com.arjuna.ats.jta] (Periodic Recovery) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:XAResourceWrapperImpl@11455a2[xaResource=org.jboss.jca.adapters.jdbc.xa.XAManagedConnection@212b9 pad=false overrideRmValue=null productName=PostgreSQL productVersion=9.1.4 jndiName=java:jboss/xa-datasources/VerificationDS], txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:3d6777ab:50f804c8:2b, node_name=1, branch_uid=0:ffff7f000001:3d6777ab:50f804c8:34, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS >, heuristic: TwoPhaseOutcome.FINISH_OK, product: PostgreSQL/9.1.4, jndiName: java:jboss/xa-datasources/CrashRecoveryDS com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@13c2797 >
> 15:25:28,568 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) BasicAction::updateState() for action-id 0:ffff7f000001:3d6777ab:50f804c8:2b
> 15:25:28,568 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.remove_committed(0:ffff7f000001:3d6777ab:50f804c8:2b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction)
> 15:25:28,568 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.remove_state(0:ffff7f000001:3d6777ab:50f804c8:2b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL)
> 15:25:28,568 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:3d6777ab:50f804c8:2b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_SHADOW)
> 15:25:28,569 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:3d6777ab:50f804c8:2b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 10)
> 15:25:28,569 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:3d6777ab:50f804c8:2b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL)
> 15:25:28,569 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:3d6777ab:50f804c8:2b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11)
> 15:25:28,569 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:3d6777ab:50f804c8:2b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) - returning StateStatus.OS_COMMITTED
> 15:25:28,569 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:3d6777ab:50f804c8:2b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL)
> 15:25:28,569 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:3d6777ab:50f804c8:2b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11)
> 15:25:28,569 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.openAndLock(/home/ochaloup/Transactions/eap-tests-transactions/integration/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/0_ffff7f000001_3d6777ab_50f804c8_2b, FileLock.F_WRLCK, false)
> 15:25:28,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.closeAndUnlock(/home/ochaloup/Transactions/eap-tests-transactions/integration/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/0_ffff7f000001_3d6777ab_50f804c8_2b, null, null)
> 15:25:28,570 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) RecoverAtomicAction.replayPhase2( 0:ffff7f000001:3d6777ab:50f804c8:2b ) finished
> 15:25:28,570 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery)
> 15:25:28,570 DEBUG [com.arjuna.ats.txoj] (Periodic Recovery) TORecoveryModule - second pass
> 15:25:28,570 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery)
> 15:25:28,570 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Local XARecoveryModule - second pass
> 15:25:28,570 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Local XARecoveryModule.transactionInitiatedRecovery completed
> 15:25:28,570 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016008: Local XARecoveryModule.xaRecovery - caught exception: java.lang.NullPointerException
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:598) [narayana-jts-jacorb-5.0.0.M2-SNAPSHOT.jar:5.0.0.M2-SNAPSHOT (revision: 1fa9d41e685713c7323222a0bb83e41ec1fd3d31)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:413) [narayana-jts-jacorb-5.0.0.M2-SNAPSHOT.jar:5.0.0.M2-SNAPSHOT (revision: 1fa9d41e685713c7323222a0bb83e41ec1fd3d31)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:193) [narayana-jts-jacorb-5.0.0.M2-SNAPSHOT.jar:5.0.0.M2-SNAPSHOT (revision: 1fa9d41e685713c7323222a0bb83e41ec1fd3d31)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789) [narayana-jts-jacorb-5.0.0.M2-SNAPSHOT.jar:5.0.0.M2-SNAPSHOT (revision: 1fa9d41e685713c7323222a0bb83e41ec1fd3d31)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.M2-SNAPSHOT.jar:5.0.0.M2-SNAPSHOT (revision: 1fa9d41e685713c7323222a0bb83e41ec1fd3d31)]
> 15:25:28,571 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Have 1 Xids to recover on this pass.
> 15:25:28,572 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) StateManager::StateManager( 2, 0 )
> 15:25:28,572 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) BasicAction::BasicAction()
> 15:25:28,572 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Checking whether Xid < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:3d6777ab:50f804c8:2b, node_name=1, branch_uid=0:ffff7f000001:3d6777ab:50f804c8:34, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS > exists in ObjectStore.
> 15:25:28,572 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Looking for 0:ffff7f000001:3d6777ab:50f804c8:2b and /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction
> 15:25:28,572 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:3d6777ab:50f804c8:2b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_SHADOW)
> 15:25:28,572 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:3d6777ab:50f804c8:2b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 10)
> 15:25:28,572 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffff7f000001:3d6777ab:50f804c8:2b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL)
> 15:25:28,572 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffff7f000001:3d6777ab:50f804c8:2b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11)
> 15:25:28,572 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffff7f000001:3d6777ab:50f804c8:2b, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) - returning StateStatus.OS_UNKNOWN
> 15:25:28,572 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) No record found for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:3d6777ab:50f804c8:2b, node_name=1, branch_uid=0:ffff7f000001:3d6777ab:50f804c8:34, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS >
> 15:25:28,573 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTATransactionLogXAResourceOrphanFilter voted ABSTAIN
> 15:25:28,573 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:3d6777ab:50f804c8:2b, node_name=1, branch_uid=0:ffff7f000001:3d6777ab:50f804c8:34, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS > is 1
> 15:25:28,573 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK
> 15:25:28,573 INFO [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016013: Rolling back < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:3d6777ab:50f804c8:2b, node_name=1, branch_uid=0:ffff7f000001:3d6777ab:50f804c8:34, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS >
> 15:25:28,746 ERROR [stderr] (Periodic Recovery) org.postgresql.xa.PGXAException: Error rolling back prepared transaction
> 15:25:28,746 ERROR [stderr] (Periodic Recovery) at org.postgresql.xa.PGXAConnection.rollback(PGXAConnection.java:416)
> 15:25:28,746 ERROR [stderr] (Periodic Recovery) at org.jboss.jca.adapters.jdbc.xa.XAManagedConnection.rollback(XAManagedConnection.java:342)
> 15:25:28,747 ERROR [stderr] (Periodic Recovery) at org.jboss.jca.core.tx.jbossts.XAResourceWrapperImpl.rollback(XAResourceWrapperImpl.java:174)
> 15:25:28,747 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.handleOrphan(XARecoveryModule.java:734)
> 15:25:28,747 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:640)
> 15:25:28,747 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:413)
> 15:25:28,747 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:193)
> 15:25:28,748 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:789)
> 15:25:28,748 ERROR [stderr] (Periodic Recovery) at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371)
> 15:25:28,748 ERROR [stderr] (Periodic Recovery) Caused by: org.postgresql.util.PSQLException: ERROR: prepared transaction with identifier "131077_AAAAAAAAAAAAAP//fwAAAT1nd6tQ+ATIAAAAKzE=_AAAAAAAAAAAAAP//fwAAAT1nd6tQ+ATIAAAANAAAAAEAAAAA" does not exist
> 15:25:28,748 ERROR [stderr] (Periodic Recovery) at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2101)
> 15:25:28,749 ERROR [stderr] (Periodic Recovery) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1834)
> 15:25:28,749 ERROR [stderr] (Periodic Recovery) at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:255)
> 15:25:28,749 ERROR [stderr] (Periodic Recovery) at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:510)
> 15:25:28,749 ERROR [stderr] (Periodic Recovery) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:372)
> 15:25:28,749 ERROR [stderr] (Periodic Recovery) at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:300)
> 15:25:28,750 ERROR [stderr] (Periodic Recovery) at org.postgresql.xa.PGXAConnection.rollback(PGXAConnection.java:406)
> 15:25:28,750 ERROR [stderr] (Periodic Recovery) ... 8 more
> 15:25:28,750 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Have 0 Xids to recover on this pass.
> 15:25:28,750 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Have 1 Xids to recover on this pass.
> 15:25:28,750 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) StateManager::StateManager( 2, 0 )
> 15:25:28,750 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) BasicAction::BasicAction()
> 15:25:28,750 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Checking whether Xid < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffff7f000001:3d6777ab:50f804c8:2b, node_name=1, branch_uid=0:ffff7f000001:3d6777ab:50f804c8:2e, subordinatenodename=null, eis_name=unknown eis name > exists in ObjectStore.
> {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
11 years, 2 months
[JBoss JIRA] (JBTM-1206) Intermittent XTS CR bug
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1206?page=com.atlassian.jira.plugin.... ]
Paul Robinson resolved JBTM-1206.
---------------------------------
Resolution: Cannot Reproduce Bug
> Intermittent XTS CR bug
> -----------------------
>
> Key: JBTM-1206
> URL: https://issues.jboss.org/browse/JBTM-1206
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing, XTS
> Reporter: Tom Jenkinson
> Assignee: Paul Robinson
> Priority: Minor
> Fix For: 4.17.4
>
>
> http://172.17.131.2/job/narayana-java7-idlj/51/
> [INFO] Surefire report directory: /home/hudson/workspace/narayana-java7-idlj/XTS/localjunit/crash-recovery-tests/target/surefire-reports
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running com.arjuna.qa.junit.TestATCrashDuringCommit
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 371.769 sec
> Running com.arjuna.qa.junit.TestATCrashDuringOnePhaseCommit
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 66.163 sec
> Running com.arjuna.qa.junit.TestATHeuristicRecoveryAfterDelayedCommit
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 369.915 sec
> Running com.arjuna.qa.junit.TestATParticipantCrashAndRecover
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 3, Time elapsed: 0 sec
> Running com.arjuna.qa.junit.TestATSubordinateCrashDuringCommit
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 149.636 sec
> Running com.arjuna.qa.junit.TestATSubordinateCrashDuringPrepare
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 74.689 sec
> Running com.arjuna.qa.junit.TestBACrashDuringCommit
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1,436.51 sec
> Running com.arjuna.qa.junit.TestBACrashDuringOnePhaseCommit
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 159.511 sec
> Running com.arjuna.qa.junit.TestBASubordinateCrashDuringCommit
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 320.848 sec
> Running com.arjuna.qa.junit.TestBASubordinateCrashDuringCommitAfterSubordinateExit
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 327.038 sec
> Running com.arjuna.qa.junit.TestBASubordinateCrashDuringComplete
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 795.378 sec <<< FAILURE!
> Results :
> Tests in error:
> subordinateMultiParticipantParticipantCompletionParticipantCloseTest(com.arjuna.qa.junit.TestBASubordinateCrashDuringComplete): jboss-as not killed and shutdown
> Tests run: 26, Failures: 0, Errors: 1, Skipped: 3
--
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
11 years, 2 months
[JBoss JIRA] (JBTM-1448) Failed to submit/remove Byteman script, because of refused connection
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1448?page=com.atlassian.jira.plugin.... ]
Paul Robinson commented on JBTM-1448:
-------------------------------------
Thanks Amos, that makes sense now.
> Failed to submit/remove Byteman script, because of refused connection
> ---------------------------------------------------------------------
>
> Key: JBTM-1448
> URL: https://issues.jboss.org/browse/JBTM-1448
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing, XTS
> Reporter: Gytis Trikleris
> Assignee: Amos Feng
> Priority: Critical
> Fix For: 4.16.7
>
> Attachments: console.txt
>
>
> See:
> http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-EAP601/312
> http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-EAP601/313
> {noformat}
> Tests in error:
> org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase: Failed to submit Byteman script
> org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase: Failed to remove Byteman script
> {noformat}
> {noformat}
> java.lang.RuntimeException: Failed to submit Byteman script
> at org.jboss.as.test.xts.simple.BMScript.submit(BMScript.java:43)
> at org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase.submitBytemanScript(WSBAParticipantCompletionTestCase.java:69)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27)
> at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:351)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
> at java.net.Socket.connect(Socket.java:529)
> at java.net.Socket.connect(Socket.java:478)
> at java.net.Socket.<init>(Socket.java:375)
> at java.net.Socket.<init>(Socket.java:189)
> at org.jboss.byteman.agent.submit.Submit$Comm.<init>(Submit.java:797)
> at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:735)
> at org.jboss.byteman.agent.submit.Submit.addScripts(Submit.java:574)
> at org.jboss.byteman.agent.submit.Submit.addRulesFromFiles(Submit.java:547)
> at org.jboss.as.test.xts.simple.BMScript.submit(BMScript.java:41)
> ... 54 more
> {noformat}
> {noformat}
> java.lang.RuntimeException: Failed to remove Byteman script
> at org.jboss.as.test.xts.simple.BMScript.remove(BMScript.java:53)
> at org.jboss.as.test.xts.simple.wsba.participantcompletion.client.WSBAParticipantCompletionTestCase.removeBytemanScript(WSBAParticipantCompletionTestCase.java:74)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36)
> at org.jboss.arquillian.junit.Arquillian$StatementLifecycleExecutor.invoke(Arquillian.java:351)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:65)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.afterClass(EventTestRunnerAdaptor.java:87)
> at org.jboss.arquillian.junit.Arquillian$3$1.evaluate(Arquillian.java:204)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.net.ConnectException: Connection refused
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
> at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
> at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
> at java.net.Socket.connect(Socket.java:529)
> at java.net.Socket.connect(Socket.java:478)
> at java.net.Socket.<init>(Socket.java:375)
> at java.net.Socket.<init>(Socket.java:189)
> at org.jboss.byteman.agent.submit.Submit$Comm.<init>(Submit.java:797)
> at org.jboss.byteman.agent.submit.Submit.submitRequest(Submit.java:735)
> at org.jboss.byteman.agent.submit.Submit.deleteScripts(Submit.java:646)
> at org.jboss.byteman.agent.submit.Submit.deleteRulesFromFiles(Submit.java:619)
> at org.jboss.as.test.xts.simple.BMScript.remove(BMScript.java:51)
> ... 54 more
> {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
11 years, 2 months
[JBoss JIRA] (JBTM-972) LifecycleHandlers implemented via an EJB are invoked directly and not via the EJB stub
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-972?page=com.atlassian.jira.plugin.s... ]
Paul Robinson commented on JBTM-972:
------------------------------------
Here's a WiP for this: https://github.com/jbosstm/jboss-as/commit/217ca527bc12972e3eed9bc747cb19...
I'm now using AS7 internal interceptors, but I can't figure out, yet, how to get hold of the EJB proxy.
> LifecycleHandlers implemented via an EJB are invoked directly and not via the EJB stub
> --------------------------------------------------------------------------------------
>
> Key: JBTM-972
> URL: https://issues.jboss.org/browse/JBTM-972
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Affects Versions: 5.0.0.M1
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Labels: TXFramework
> Fix For: 5.0.0.M2
>
> Original Estimate: 1 day
> Time Spent: 2 hours
> Remaining Estimate: 6 hours
>
> eFor a EJB service, the service method is invoked via the EJB stub. Notice the stack bellow:
> {code}
> http-localhost-127.0.0.1-8080-2@444 daemon, prio=5, in group 'main', status: 'runnable'
> java.lang.Thread.State: RUNNABLE
> at org.jboss.narayana.txframework.functional.services.ATService.invoke(ATService.java:69)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
> at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:80)
> at org.jboss.narayana.txframework.impl.handlers.wsat.WSATHandler.proceed(WSATHandler.java:58)
> at org.jboss.narayana.txframework.impl.ServiceRequestInterceptor.intercept(ServiceRequestInterceptor.java:23)
> {code}
> However, when the lifecycle methods are invoked, they are invoked directly. Notice the missing org.jboss calls bellow the sun.reflect calls in the stacktrace bellow:
> {code}
> TaskWorker-4@504 daemon, prio=5, in group 'default-workqueue', status: 'runnable'
> java.lang.Thread.State: RUNNABLE
> at org.jboss.narayana.txframework.functional.services.ATService.commit(ATService.java:110)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.narayana.txframework.impl.Participant.invoke(Participant.java:53)
> at org.jboss.narayana.txframework.impl.handlers.wsat.WSATDurable2PCParticipant.commit(WSATDurable2PCParticipant.java:18)
> {code}
> This is likely to cause a problem as the EJB instance may be destroyed, or re-used when the lifecycle method is invoked.
--
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
11 years, 3 months
[JBoss JIRA] (JBTM-972) LifecycleHandlers implemented via an EJB are invoked directly and not via the EJB stub
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-972?focusedWorklogId=12428607&page=c... ]
Paul Robinson logged work on JBTM-972:
--------------------------------------
Author: Paul Robinson
Created on: 04/Feb/13 1:51 PM
Start Date: 04/Feb/13 1:51 PM
Worklog Time Spent: 1 day
Issue Time Tracking
-------------------
Remaining Estimate: 1 day (was: 6 hours)
Time Spent: 1 day, 2 hours (was: 2 hours)
Worklog Id: (was: 12428607)
> LifecycleHandlers implemented via an EJB are invoked directly and not via the EJB stub
> --------------------------------------------------------------------------------------
>
> Key: JBTM-972
> URL: https://issues.jboss.org/browse/JBTM-972
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Affects Versions: 5.0.0.M1
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Labels: TXFramework
> Fix For: 5.0.0.M2
>
> Original Estimate: 1 day
> Time Spent: 1 day, 2 hours
> Remaining Estimate: 1 day
>
> eFor a EJB service, the service method is invoked via the EJB stub. Notice the stack bellow:
> {code}
> http-localhost-127.0.0.1-8080-2@444 daemon, prio=5, in group 'main', status: 'runnable'
> java.lang.Thread.State: RUNNABLE
> at org.jboss.narayana.txframework.functional.services.ATService.invoke(ATService.java:69)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
> at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:80)
> at org.jboss.narayana.txframework.impl.handlers.wsat.WSATHandler.proceed(WSATHandler.java:58)
> at org.jboss.narayana.txframework.impl.ServiceRequestInterceptor.intercept(ServiceRequestInterceptor.java:23)
> {code}
> However, when the lifecycle methods are invoked, they are invoked directly. Notice the missing org.jboss calls bellow the sun.reflect calls in the stacktrace bellow:
> {code}
> TaskWorker-4@504 daemon, prio=5, in group 'default-workqueue', status: 'runnable'
> java.lang.Thread.State: RUNNABLE
> at org.jboss.narayana.txframework.functional.services.ATService.commit(ATService.java:110)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.narayana.txframework.impl.Participant.invoke(Participant.java:53)
> at org.jboss.narayana.txframework.impl.handlers.wsat.WSATDurable2PCParticipant.commit(WSATDurable2PCParticipant.java:18)
> {code}
> This is likely to cause a problem as the EJB instance may be destroyed, or re-used when the lifecycle method is invoked.
--
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
11 years, 3 months
[JBoss JIRA] (JBTM-972) LifecycleHandlers implemented via an EJB are invoked directly and not via the EJB stub
by Paul Robinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-972?page=com.atlassian.jira.plugin.s... ]
Paul Robinson commented on JBTM-972:
------------------------------------
Apparently it's not possible to get the proxy from a CDI interceptor. I'm currently investigating replacing the CDI interceptor with an internal AS7 interceptor. This has the added benefit that:
* It works if CDI is disabled.
* The developer doesn't have to enable the interceptor in the beans.xml
* The application method does not need to be annotated, if we decide the API would be better without it. Currently it must be annotated with @ServiceRequest to have the CDi interceptor fire.
> LifecycleHandlers implemented via an EJB are invoked directly and not via the EJB stub
> --------------------------------------------------------------------------------------
>
> Key: JBTM-972
> URL: https://issues.jboss.org/browse/JBTM-972
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: TXFramework
> Affects Versions: 5.0.0.M1
> Reporter: Paul Robinson
> Assignee: Paul Robinson
> Labels: TXFramework
> Fix For: 5.0.0.M2
>
> Original Estimate: 1 day
> Time Spent: 2 hours
> Remaining Estimate: 6 hours
>
> eFor a EJB service, the service method is invoked via the EJB stub. Notice the stack bellow:
> {code}
> http-localhost-127.0.0.1-8080-2@444 daemon, prio=5, in group 'main', status: 'runnable'
> java.lang.Thread.State: RUNNABLE
> at org.jboss.narayana.txframework.functional.services.ATService.invoke(ATService.java:69)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
> at org.jboss.as.weld.ejb.DelegatingInterceptorInvocationContext.proceed(DelegatingInterceptorInvocationContext.java:80)
> at org.jboss.narayana.txframework.impl.handlers.wsat.WSATHandler.proceed(WSATHandler.java:58)
> at org.jboss.narayana.txframework.impl.ServiceRequestInterceptor.intercept(ServiceRequestInterceptor.java:23)
> {code}
> However, when the lifecycle methods are invoked, they are invoked directly. Notice the missing org.jboss calls bellow the sun.reflect calls in the stacktrace bellow:
> {code}
> TaskWorker-4@504 daemon, prio=5, in group 'default-workqueue', status: 'runnable'
> java.lang.Thread.State: RUNNABLE
> at org.jboss.narayana.txframework.functional.services.ATService.commit(ATService.java:110)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.jboss.narayana.txframework.impl.Participant.invoke(Participant.java:53)
> at org.jboss.narayana.txframework.impl.handlers.wsat.WSATDurable2PCParticipant.commit(WSATDurable2PCParticipant.java:18)
> {code}
> This is likely to cause a problem as the EJB instance may be destroyed, or re-used when the lifecycle method is invoked.
--
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
11 years, 3 months
[JBoss JIRA] (JBTM-1369) Benchmark performance difference between JacORB and JDK ORB
by Gytis Trikleris (JIRA)
[ https://issues.jboss.org/browse/JBTM-1369?page=com.atlassian.jira.plugin.... ]
Work on JBTM-1369 started by Gytis Trikleris.
> Benchmark performance difference between JacORB and JDK ORB
> -----------------------------------------------------------
>
> Key: JBTM-1369
> URL: https://issues.jboss.org/browse/JBTM-1369
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JTS, Performance Testing
> Affects Versions: 4.17.0
> Reporter: Michael Musgrove
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M2
>
>
> JBTM-934 added support for the JDK orb to JTS. IOR sizes can range in size from 512 bytes to entirely unbounded, with the ORB being able to add arbitrary data within specific portions. Since the IOR is packed into transaction logs and if the IOR sizes are significantly different we may find that transaction throughput has been improved or degraded. We should run some benchmarks to see what the impact is.
--
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
11 years, 3 months
[JBoss JIRA] (JBTM-1369) Benchmark performance difference between JacORB and JDK ORB
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-1369?page=com.atlassian.jira.plugin.... ]
Michael Musgrove reassigned JBTM-1369:
--------------------------------------
Assignee: Gytis Trikleris (was: Michael Musgrove)
Initially this work should use our existing EJB performance benchmark using Stewart's jdkorb branch.
Subsequently we should include it it the QA test suite.
> Benchmark performance difference between JacORB and JDK ORB
> -----------------------------------------------------------
>
> Key: JBTM-1369
> URL: https://issues.jboss.org/browse/JBTM-1369
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: JTS, Performance Testing
> Affects Versions: 4.17.0
> Reporter: Michael Musgrove
> Assignee: Gytis Trikleris
> Fix For: 5.0.0.M2
>
>
> JBTM-934 added support for the JDK orb to JTS. IOR sizes can range in size from 512 bytes to entirely unbounded, with the ORB being able to add arbitrary data within specific portions. Since the IOR is packed into transaction logs and if the IOR sizes are significantly different we may find that transaction throughput has been improved or degraded. We should run some benchmarks to see what the impact is.
--
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
11 years, 3 months