September 2014 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2259) Allow the ordering of some synchronizations to be configurable

by Michael Musgrove (JIRA)

Michael Musgrove created JBTM-2259: -------------------------------------- Summary: Allow the ordering of some synchronizations to be configurable Key: JBTM-2259 URL: https://issues.jboss.org/browse/JBTM-2259 Project: JBoss Transaction Manager Issue Type: Enhancement Components: JTA Affects Versions: 5.0.3 Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.0.4 IronJacamar delists resources in a beforeCompletion synchronization but under certain circumstances (see attached forum thread) it may run before all JPA persistence providers beforeCompletion synchronizations have been called (which breaks JPA). The request is to add a configuration option to control the order in which certain synchronizations are called. -- 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: ----------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1145513|https://bugzilla.redhat.com/show_bug.cgi?id=1145513] from NEW to CLOSED > 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 updated JBTM-2242: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1133346, https://bugzilla.redhat.com/show_bug.cgi?id=1143956 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1133346) > 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 updated JBTM-2241: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1143947, https://bugzilla.redhat.com/show_bug.cgi?id=1143956, https://bugzilla.redhat.com/show_bug.cgi?id=1145513 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1143947, https://bugzilla.redhat.com/show_bug.cgi?id=1143956) > 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-2258) Update the build process to build a binary distribution of Narayana during normal install phase

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2258?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2258: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/733 > Update the build process to build a binary distribution of Narayana during normal install phase > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2258 > URL: https://issues.jboss.org/browse/JBTM-2258 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.0.4 > > > ./build.sh install (or just ./build.sh - install is the default) should build the release zip. > We have removed the JavaDocs from the dist as these are available online (including previous versions) and this is consistent with not including the docs either. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2258) Update the build process to build a binary distribution of Narayana during normal install phase

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2258?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2258: -------------------------------- Description: ./build.sh install (or just ./build.sh - install is the default) should build the release zip. We have removed the JavaDocs from the dist as these are available online (including previous versions) and this is consistent with not including the docs either. was:Do not include the Javadocs as these are all available online and this is consistent with not including the docs any more too. > Update the build process to build a binary distribution of Narayana during normal install phase > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2258 > URL: https://issues.jboss.org/browse/JBTM-2258 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.0.4 > > > ./build.sh install (or just ./build.sh - install is the default) should build the release zip. > We have removed the JavaDocs from the dist as these are available online (including previous versions) and this is consistent with not including the docs either. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2258) Update the build process to build a binary distribution of Narayana during normal install phase

by Tom Jenkinson (JIRA)

Tom Jenkinson created JBTM-2258: ----------------------------------- Summary: Update the build process to build a binary distribution of Narayana during normal install phase Key: JBTM-2258 URL: https://issues.jboss.org/browse/JBTM-2258 Project: JBoss Transaction Manager Issue Type: Task Components: Build System Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.0.4 Do not include the Javadocs as these are all available online and this is consistent with not including the docs any more too. -- 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 NEW to ASSIGNED > 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-2256) Race condition between recovery manager initialization and expiry scanner

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBTM-2256?page=com.atlassian.jira.plugin.... ] Mark Little commented on JBTM-2256: ----------------------------------- OK. I'm more interested in ensuring we have some (semi)automated test to verify the fix and that nothing like this creeps in again. How that is done is not that important. > 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-1639) Improve XTS Api for looking up Recovery Manager to prevent developer from poling

by Paul Robinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1639?page=com.atlassian.jira.plugin.... ] Paul Robinson updated JBTM-1639: -------------------------------- Reporter: Paul Robinson (was: Gytis Trikleris) > Improve XTS Api for looking up Recovery Manager to prevent developer from poling > -------------------------------------------------------------------------------- > > Key: JBTM-1639 > URL: https://issues.jboss.org/browse/JBTM-1639 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: XTS > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Fix For: 6.0.0 > > > Currently the developer needs to poll for the RecoveryManager as it's possible that the application can be deployed before the XTS subsystem has finished startup. > This issue was worked around in JBTM-1522 and in the TXBridge tests, by having the application poll until the RM was not null. > Two possible solutions: > Have a blocking call to XTSATRecoveryManager.getRecoveryManager() that doesn't return until there is an RM available. if we use the existing java method, we need to analyse all usages to make sure returning null is not a valid outcome. > Another solution is to find out how to delay the application's initialisation until after XTS has started. This puts the burden on the application developer to implement, but requires no changes to the XTS code. See JBTM-1522 for alternative mechanisms for initialising the application. I tried three and none of them fired after the server had booted. > To Reproduce > Put breakpoints on: > Application's usage of: XTSATRecoveryManager.getRecoveryManager(); //Stop all threads > XTSATRecoveryManager.setRecoveryManager() // stop on Thread only > Copy your application to the deploy directory (xtstest.war is a good choice). Now start the server with debugging enabled (suspend=y). To reproduce this you will see the XTSATRecoveryManager.setRecoveryManager() BP fire, and then shortly after the XTSATRecoveryManager.getRecoveryManager() BP will fire. Allow the getRecoveryManager to continue and you will notice it is null. Fix this problem, and the getRecoveryManager will wait until the setRecoveryManager is complete and thus always return a non-null RM. > Once this is fixed, find all occurrence of the polling work-around and have them use the solution to this issue. -- 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