April 2015 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2330) Document the procedure to discover and resolve heuristically completed branches in Narayana

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2330?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2330: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/documentation/pull/30 > Document the procedure to discover and resolve heuristically completed branches in Narayana > ------------------------------------------------------------------------------------------- > > Key: JBTM-2330 > URL: https://issues.jboss.org/browse/JBTM-2330 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.x.y > > > Our documentation is not complete in this area. We need to describe how users can detect heuristically completed branches in the system. It would be useful to consider this in standalone and embedded wildfly modes. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2359) cersei needs libaio-devel installing, causes txfooapp quickstart failed with missing the libaio.so

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2359?page=com.atlassian.jira.plugin.... ] Amos Feng resolved JBTM-2359. ----------------------------- Resolution: Done > cersei needs libaio-devel installing, causes txfooapp quickstart failed with missing the libaio.so > -------------------------------------------------------------------------------------------------- > > Key: JBTM-2359 > URL: https://issues.jboss.org/browse/JBTM-2359 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.0.5 > > > http://albany.eng.hst.ams2.redhat.com/view/Narayana+BlackTie/job/narayana... > {noformat} > [exec] [cc] /usr/bin/ld: warning: libaio.so.1, needed by instantclient_11_2/lib/libclntsh.so, not found (try using -rpath or -rpath-link) > [exec] > [exec] BUILD SUCCESSFUL > [exec] Total time: 3 seconds > [exec] [cc] /usr/bin/ld: warning: libaio.so.1, needed by instantclient_11_2/lib/libclntsh.so, not found (try using -rpath or -rpath-link) > [exec] > [exec] BUILD SUCCESSFUL > [exec] Total time: 3 seconds > [exec] Checking for host: cersei.eng.hst.ams2.redhat.com or ip: 10.39.168.24 > [exec] ./server: error while loading shared libraries: libaio.so.1: cannot open shared object file: No such file or directory > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2183) Need finer grained control over which XAResource is used for recovery

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2183?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2183: -------------------------------- Fix Version/s: 6.x.y (was: 5.x.y) > Need finer grained control over which XAResource is used for recovery > --------------------------------------------------------------------- > > Key: JBTM-2183 > URL: https://issues.jboss.org/browse/JBTM-2183 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Affects Versions: 4.17.20, 5.0.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 6.x.y > > > During recovery when we recreate an XAResource we need one which knows about the xid that is being recovered. We implement this in the XARecoveryModule which calls recover() on each resource returned by registered XA recovery helpers. If the xid returned from recover matches against the one we are recovering we use that XAResource to drive recovery. > However, some RMs will return all prepared transaction branches and not just the ones specific to the particular resource we made the recover call on. The scenario that led to the issue was configuring 2 datasources against the same database but with different credentials. If we replay the commit on the "wrong" one we get ORA-24774: "The transaction specified in the call refers to a transaction created by a different user". > The fix is to return an XA resource that matches the JNDI name we logged in the recovery record and if the JNDI name is not available we drop back to using the current solution (note that the name is available when running in wildfly/EAP) . > And finally, I I wonder if we want to make this new behaviour optional? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2183) Need finer grained control over which XAResource is used for recovery

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2183?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2183: -------------------------------- Issue Type: Enhancement (was: Bug) > Need finer grained control over which XAResource is used for recovery > --------------------------------------------------------------------- > > Key: JBTM-2183 > URL: https://issues.jboss.org/browse/JBTM-2183 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Affects Versions: 4.17.20, 5.0.1 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 6.x.y > > > During recovery when we recreate an XAResource we need one which knows about the xid that is being recovered. We implement this in the XARecoveryModule which calls recover() on each resource returned by registered XA recovery helpers. If the xid returned from recover matches against the one we are recovering we use that XAResource to drive recovery. > However, some RMs will return all prepared transaction branches and not just the ones specific to the particular resource we made the recover call on. The scenario that led to the issue was configuring 2 datasources against the same database but with different credentials. If we replay the commit on the "wrong" one we get ORA-24774: "The transaction specified in the call refers to a transaction created by a different user". > The fix is to return an XA resource that matches the JNDI name we logged in the recovery record and if the JNDI name is not available we drop back to using the current solution (note that the name is available when running in wildfly/EAP) . > And finally, I I wonder if we want to make this new behaviour optional? -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2137) JDBCStore recovery is too slow

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2137?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2137: -------------------------------- Issue Type: Enhancement (was: Bug) > JDBCStore recovery is too slow > ------------------------------ > > Key: JBTM-2137 > URL: https://issues.jboss.org/browse/JBTM-2137 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.x.y > > > The linked CI job failed because the STATESTOREJBOSSTSTXTABLE had too many entries (>600) and this caused the recovery pass to take about 15 minutes which in turn causes subsequent tests to time out. The reason for so many entries is covered by JBTM-2133 but this JIRA is for the poor performance when there are so many entries. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2330) Document the procedure to discover and resolve heuristically completed branches in Narayana

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2330?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2330: -------------------------------- Issue Type: Task (was: Feature Request) > Document the procedure to discover and resolve heuristically completed branches in Narayana > ------------------------------------------------------------------------------------------- > > Key: JBTM-2330 > URL: https://issues.jboss.org/browse/JBTM-2330 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.x.y > > > Our documentation is not complete in this area. We need to describe how users can detect heuristically completed branches in the system. It would be useful to consider this in standalone and embedded wildfly modes. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2360) QA suite failure: org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery05_2 crashrecovery05_2 CrashRecovery05_2_Test045 Fail

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2360?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2360: -------------------------------- Issue Type: Bug (was: Feature Request) > QA suite failure: org.jboss.jbossts.qa.junit.testgroup.TestGroup_crashrecovery05_2 crashrecovery05_2 CrashRecovery05_2_Test045 Fail > ----------------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2360 > URL: https://issues.jboss.org/browse/JBTM-2360 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.x.y > > > http://albany.eng.hst.ams2.redhat.com/view/Narayana+BlackTie/job/narayana... > I had a look and there are some messages that suggest that the connection was broken. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2335) Removing CORBA in JATMI

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2335?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2335: -------------------------------- Issue Type: Task (was: Feature Request) > Removing CORBA in JATMI > ----------------------- > > Key: JBTM-2335 > URL: https://issues.jboss.org/browse/JBTM-2335 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.x.y > > > Currently we are still using the OrbManagement, it needs to be removed as we have not supported the OTS Transaction in Blacktie transport. It also need to port the JATMI code to use RTS. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2361) Remove dependency on test-utils

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2361?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2361: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Remove dependency on test-utils > ------------------------------- > > Key: JBTM-2361 > URL: https://issues.jboss.org/browse/JBTM-2361 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Performance Testing > Affects Versions: 5.0.4 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.5 > > > The benchmark testsuite has a historical dependency on artifact org.jboss.narayana:test-utils which should now be removed. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1572) a failure in the txfooapp quickstart does not return -1 so it appears to run even when it hasn't

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-1572?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-1572: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > a failure in the txfooapp quickstart does not return -1 so it appears to run even when it hasn't > ------------------------------------------------------------------------------------------------ > > Key: JBTM-1572 > URL: https://issues.jboss.org/browse/JBTM-1572 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.0.5 > > Attachments: client.valgrind, JBTM-1572.txt, JBTM-1572.zip, server.valgrind, windbg.out > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Note, it will definitely be worth doing this in a branch/pull as I suspect the database isn't running atm so that will need a kick too -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 2 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 April 2015