September 2014 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2256) Race condition between recovery manager initialization and expiry scanner

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-2256: ----------------------------------------------- tom.jenkinson(a)redhat.com changed the Status of [bug 1104584|https://bugzilla.redhat.com/show_bug.cgi?id=1104584] from NEW to MODIFIED > Race condition between recovery manager initialization and expiry scanner > ------------------------------------------------------------------------- > > Key: JBTM-2256 > URL: https://issues.jboss.org/browse/JBTM-2256 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > In a constructor of RecoveryManagerImple expiry scanner is started before initiating PeriodicRecovery. This causes a problem from time to time, because during the initiation of PeriodicRecovery (more exact XARecoveryModule) ExtendedResourceRecord is added to the RecordTypeManager. It has to be there during the expiry scan execution. Since expiry scanner works in a separate thread it works most of the time, but race condition still exists. Personally I couldn't reproduce the problem. > Swapping these two actions should solve the problem. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2255) Do not return StatusCommiting, if transaction was commited by the original transaction manager

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2255?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-2255: ----------------------------------------------- tom.jenkinson(a)redhat.com changed the Status of [bug 1080035|https://bugzilla.redhat.com/show_bug.cgi?id=1080035] from NEW to MODIFIED > Do not return StatusCommiting, if transaction was commited by the original transaction manager > ---------------------------------------------------------------------------------------------- > > Key: JBTM-2255 > URL: https://issues.jboss.org/browse/JBTM-2255 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.4 > > > We need to check if the transaction is really in flight before returning status as committing. Previously code assumed, that if returned status is StatusCommitted, the only reason why the resource invoked replay_completion is that the transaction is in the process of committing. > However, as shown by the attached bugzilla, another work flow is also possible. Because Oracle database returned XAException.XAER_RMFAIL, second resource was committed successfully and the client was told that the transaction committed successfully. Recovery was left to sort out the issue with the database. Once the database resource invoked replay_completion and transaction manager saw the status of the transaction as StatusCommitted, it assumed that it is still in action even though there is no BasicAction available. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1341) Reject setting node identifier on CoreEnvironmentBean unless it can be successfully used by TxControl

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-1341?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-1341: ----------------------------------------------- tom.jenkinson(a)redhat.com changed the Status of [bug 1139102|https://bugzilla.redhat.com/show_bug.cgi?id=1139102] from NEW to MODIFIED > Reject setting node identifier on CoreEnvironmentBean unless it can be successfully used by TxControl > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-1341 > URL: https://issues.jboss.org/browse/JBTM-1341 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 4.17.23, 5.0.0.M2 > > > It is too easy to miss the warning message. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2238) Tooling does not expose CMR records

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2238?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-2238: ----------------------------------------------- tom.jenkinson(a)redhat.com changed the Status of [bug 1113225|https://bugzilla.redhat.com/show_bug.cgi?id=1113225] from ASSIGNED to MODIFIED > Tooling does not expose CMR records > ----------------------------------- > > Key: JBTM-2238 > URL: https://issues.jboss.org/browse/JBTM-2238 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Tooling > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > CMR resources are not being exposed as MBeans via the (com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser) tooling. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2241) Removal of RecoveryHelpers fails silently if no scan is in progress

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2241?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-2241: ----------------------------------------------- tom.jenkinson(a)redhat.com changed the Status of [bug 1143947|https://bugzilla.redhat.com/show_bug.cgi?id=1143947] from ASSIGNED to MODIFIED > Removal of RecoveryHelpers fails silently if no scan is in progress > ------------------------------------------------------------------- > > Key: JBTM-2241 > URL: https://issues.jboss.org/browse/JBTM-2241 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > There is some code in XARecoveryModule#removeXAResourceRecoveryHelper that defers removal of recovery helpers if a scan is in progress but skips the removal otherwise. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2242) Misbehaving XAResources may delay deployments

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2242?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-2242: ----------------------------------------------- tom.jenkinson(a)redhat.com changed the Status of [bug 1133346|https://bugzilla.redhat.com/show_bug.cgi?id=1133346] from ASSIGNED to MODIFIED > Misbehaving XAResources may delay deployments > --------------------------------------------- > > Key: JBTM-2242 > URL: https://issues.jboss.org/browse/JBTM-2242 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.4 > > > Recovery scans can delay subsystem deployments because of contention on the lock XARecoveryModule#_xaResourceRecoveryHelpers: > XARecoveryModule#resourceInitiatedRecoveryForRecoveryHelpers takes the lock and then makes calls to the resource which can potentially hang transiently. Meanwhile, deployments which register recovery helpers are delayed whilst waiting for the lock to be released (in XARecoveryModule#addXAResourceRecoveryHelper). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.... ] Tom Jenkinson commented on JBTM-2264: ------------------------------------- Hi Evgeniy, This issue comes about due to different handling of detecting duplicate XAResources when enlistResource is called on a transaction. With Bitronix (and possibly Atomikos) when an XAR is enlisted pointer comparison is used to detect whether or not an equivalent XAR is registered. With Narayana we use isSameRM to detect if the XAR are equivalent, even if they have different references. With BTM, it means that two different Xid are enlisted for the same resource manager, with Narayana it should have allowed us to use a single Xid for the two connections. In concrete terms your test leads to Narayana issuing the following calls: {quote} xaResource1.start(xid1, TMNOFLAGS) xaResource2.start(xid1, TMJOIN) {quote} Unfortunately with Oracle that results in an exception as you have found when the driver reports that the two XAresources are for the same resource manager. When Narayana is deployed in WildFly or EAP there is code in our JCA there to override the isSameRM method such that it will return false for Oracle and the two Xids would be created similar to BTM. I am still looking into this and will update you next week, Tom > Error enlisting second xa resource on the same oracle instance but other schema > ------------------------------------------------------------------------------- > > Key: JBTM-2264 > URL: https://issues.jboss.org/browse/JBTM-2264 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.3 > Reporter: Evgeniy Smelik > Assignee: Tom Jenkinson > Attachments: sscce.zip, sscce.zip, test.log > > > I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema. > Whole stack trace: > {noformat} > oracle.jdbc.xa.OracleXAException > at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110) > at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741) > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) > java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > {noformat} > (Detail log and SSCCE are attached). > I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances. > I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not. > I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-...]. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2242) Misbehaving XAResources may delay deployments

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2242?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-2242: ----------------------------------------------- tom.jenkinson(a)redhat.com changed the Status of [bug 1143956|https://bugzilla.redhat.com/show_bug.cgi?id=1143956] from NEW to POST > Misbehaving XAResources may delay deployments > --------------------------------------------- > > Key: JBTM-2242 > URL: https://issues.jboss.org/browse/JBTM-2242 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Application Server Integration > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.4 > > > Recovery scans can delay subsystem deployments because of contention on the lock XARecoveryModule#_xaResourceRecoveryHelpers: > XARecoveryModule#resourceInitiatedRecoveryForRecoveryHelpers takes the lock and then makes calls to the resource which can potentially hang transiently. Meanwhile, deployments which register recovery helpers are delayed whilst waiting for the lock to be released (in XARecoveryModule#addXAResourceRecoveryHelper). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2241) Removal of RecoveryHelpers fails silently if no scan is in progress

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBTM-2241?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JBTM-2241: ----------------------------------------------- tom.jenkinson(a)redhat.com changed the Status of [bug 1143956|https://bugzilla.redhat.com/show_bug.cgi?id=1143956] from NEW to POST > Removal of RecoveryHelpers fails silently if no scan is in progress > ------------------------------------------------------------------- > > Key: JBTM-2241 > URL: https://issues.jboss.org/browse/JBTM-2241 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 4.17.22, 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.23, 5.0.3 > > > There is some code in XARecoveryModule#removeXAResourceRecoveryHelper that defers removal of recovery helpers if a scan is in progress but skips the removal otherwise. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2264) Error enlisting second xa resource on the same oracle instance but other schema

by Evgeniy Smelik (JIRA)

[ https://issues.jboss.org/browse/JBTM-2264?page=com.atlassian.jira.plugin.... ] Evgeniy Smelik updated JBTM-2264: --------------------------------- Attachment: sscce.zip > Error enlisting second xa resource on the same oracle instance but other schema > ------------------------------------------------------------------------------- > > Key: JBTM-2264 > URL: https://issues.jboss.org/browse/JBTM-2264 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.0.3 > Reporter: Evgeniy Smelik > Assignee: Tom Jenkinson > Attachments: sscce.zip, sscce.zip, test.log > > > I've got an exception {{java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed}} while preparing statement in the second connection within the same oracle instance but other schema. > Whole stack trace: > {noformat} > oracle.jdbc.xa.OracleXAException > at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:1110) > at oracle.jdbc.xa.client.OracleXAResource.start(OracleXAResource.java:240) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.enlistResource(TransactionImple.java:741) > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:983) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134) > java.sql.SQLException: ConnectionImple.registerDatabase - ARJUNA017017: enlist of resource failed > at com.arjuna.ats.internal.jdbc.ConnectionImple.registerDatabase(ConnectionImple.java:1003) > at com.arjuna.ats.internal.jdbc.ConnectionImple.prepareStatement(ConnectionImple.java:179) > at SimpleJdbcTest.insert(SimpleJdbcTest.java:46) > at SimpleJdbcTest.main(SimpleJdbcTest.java:36) > {noformat} > (Detail log and SSCCE are attached). > I use jboss transaction manager in standaloine application just to test jboss JTA implementation. The same code works well if one and second data sources use own (different) database instances. > I note that atomikos and bitronix JTA implementation works correctly in the same environment irrespectively single oracle instance is used or not. > I found similar problem [here|http://stackoverflow.com/questions/23617179/jboss-6-1-unable-to-get-...]. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues September 2014