March 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1602) Determine why 4 locks acquired in LockManager.propagate

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1602?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-1602: ---------------------------------------- I know that we may potentially be acquiring the same lock twice but these are re-entrant locks so I took the point of view that the code was simpler if we just retook the lock rather than adding more conditional logic. > Determine why 4 locks acquired in LockManager.propagate > ------------------------------------------------------- > > Key: JBTM-1602 > URL: https://issues.jboss.org/browse/JBTM-1602 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Mark Little > Assignee: Mark Little > -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1522) "no XTS application recovery module found" during XTS Recovery Tests

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1522?page=com.atlassian.jira.plugin.... ] Gytis Trikleris commented on JBTM-1522: --------------------------------------- http://172.17.131.2/job/narayana-JBTM-1522/82 > "no XTS application recovery module found" during XTS Recovery Tests > -------------------------------------------------------------------- > > Key: JBTM-1522 > URL: https://issues.jboss.org/browse/JBTM-1522 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Testing, XTS > Reporter: Paul Robinson > Assignee: Amos Feng > Priority: Critical > Fix For: 5.0.0.M3 > > > See: http://172.17.131.2/view/Narayana+BlackTie/job/narayana/211/artifact/XTS/... > Notice the following log is displayed repeatedly until the test gives up waiting for recovery: > {code} > WARN [com.arjuna.wsrecovery] (Periodic Recovery) ARJUNA046032: no XTS application recovery module found to help reactivate recovered WS-AT participant org.jboss.jbossts.xts.servicetests.DurableTestParticipant.0 > {code} > This error comes from org.jboss.jbossts.xts.recovery.participant.at.XTSATRecoveryManagerImple#recoverParticipants(). In particular: > {code} > if (!found) { > // we failed to find a helper to convert a participant record so log a warning > // but leave it in the table for next time > RecoveryLogger.i18NLogger.warn_participant_at_XTSATRecoveryModule_4(participantRecoveryRecord.getId()); > } > {code} > It looks like the code is unable to restore the participant from the log due to restoreParticipant(XTSATRecoveryModule module) returning false. There is ParticipantRecoveryRecord in the log as you can see it dumped to the console in the above log. Maybe there is a problem with that log, or maybe we are missing another log entry? > This problem is intermittent, so it's unlikely that you will see this happen when you attach a debugger. However, we could attach a debugger to see what happens in the normal case and also to inspect the log to see if anything is missing in the failing case. But I have a cunning plan... > h4.Cunning Plan > We need to get a copy of the failing log, before recovery is attempted. We should then be able to use that log to reproduce the issue on our own machines. Steps to take: > # Update BaseCrashTest to copy the contents of the tx-object-store to a unique folder location (So we can retrieve it later for a failed run). Make sure you create the folder structure under target/surefire-reports so that CI archives it off. Do the copy between controller.kill and controller.start. This way we get the log before the recovery manager has had chance to tamper with it. > # Update the "narayana-JBTM-1522" job in CI to use your branch, containing the change above. > # Configure the job to run @hourly until it fails with this problem. > # Take a copy of the tx-object-store from the failing test and then put it in place on your AS8 build. > # Boot the AS and confirm that the issue is reproduced. > # You can now keep putting the tx-object-store back in place every time you need to reproduce the issue. > # Attach a debugger to find out what the problem 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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1602) Determine why 4 locks acquired in LockManager.propagate

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1602?page=com.atlassian.jira.plugin.... ] Michael Musgrove edited comment on JBTM-1602 at 3/30/13 1:10 PM: ----------------------------------------------------------------- The linked JIRA explains why 4 locks are required. The second explanation in that JIRA explains the need for the extra two locks. was (Author: mmusgrov): The linked JIRA explains why 4 locks are required > Determine why 4 locks acquired in LockManager.propagate > ------------------------------------------------------- > > Key: JBTM-1602 > URL: https://issues.jboss.org/browse/JBTM-1602 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Mark Little > Assignee: Mark Little > -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1605) Integrate STM with vert.x

by Mark Little (JIRA)

Mark Little created JBTM-1605: --------------------------------- Summary: Integrate STM with vert.x Key: JBTM-1605 URL: https://issues.jboss.org/browse/JBTM-1605 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: STM Affects Versions: 5.0.0.M2 Reporter: Mark Little Assignee: Mark Little Finish the work started last year. Actor+transaction model. Due to the typical way vert.x works (one thread per task, unique classloader instance etc.), shared state is typically not a concern even between threads. STM still useful to ensure atomic updates in the presence of failures, or sharing via message passing. However, with our STM implementation, persistent instances can be shared between threads or processes in different address spaces if needed. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1604) Add auto-retry (batch) for STM

by Mark Little (JIRA)

Mark Little created JBTM-1604: --------------------------------- Summary: Add auto-retry (batch) for STM Key: JBTM-1604 URL: https://issues.jboss.org/browse/JBTM-1604 Project: JBoss Transaction Manager Issue Type: Feature Request Security Level: Public (Everyone can see) Components: STM Affects Versions: 5.0.0.M2 Reporter: Mark Little Assignee: Mark Little Add a batching mechanism for applications to use for registering tasks/updates etc. on STM object instances. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1603) STM deadlock with auto-retry

by Mark Little (JIRA)

Mark Little created JBTM-1603: --------------------------------- Summary: STM deadlock with auto-retry Key: JBTM-1603 URL: https://issues.jboss.org/browse/JBTM-1603 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: STM, Transaction Core Affects Versions: 5.0.0.M2 Reporter: Mark Little Assignee: Mark Little Fix For: 5.0.0.M3 Adding auto-retry (batching) to STM results in deadlocks now and then as number of concurrent threads increases. Hard to reproduce. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1602) Determine why 4 locks acquired in LockManager.propagate

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBTM-1602?page=com.atlassian.jira.plugin.... ] Mark Little commented on JBTM-1602: ----------------------------------- May also be related to https://issues.jboss.org/browse/JBTM-1211 Would be good if the git commit comment included the JIRA reference. > Determine why 4 locks acquired in LockManager.propagate > ------------------------------------------------------- > > Key: JBTM-1602 > URL: https://issues.jboss.org/browse/JBTM-1602 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Mark Little > Assignee: Mark Little > -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1602) Determine why 4 locks acquired in LockManager.propagate

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBTM-1602?page=com.atlassian.jira.plugin.... ] Mark Little commented on JBTM-1602: ----------------------------------- This change appears to be causing issues with some STM updates I'm looking at (performance and deadlock). > Determine why 4 locks acquired in LockManager.propagate > ------------------------------------------------------- > > Key: JBTM-1602 > URL: https://issues.jboss.org/browse/JBTM-1602 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Mark Little > Assignee: Mark Little > -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1602) Determine why 4 locks acquired in LockManager.propagate

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBTM-1602?page=com.atlassian.jira.plugin.... ] Mark Little updated JBTM-1602: ------------------------------ Summary: Determine why 4 locks acquired in LockManager.propagate (was: Determine why 4 locks acquired in propagate) > Determine why 4 locks acquired in LockManager.propagate > ------------------------------------------------------- > > Key: JBTM-1602 > URL: https://issues.jboss.org/browse/JBTM-1602 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Mark Little > Assignee: Mark Little > -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1602) Determine why 4 locks acquired in propagate

by Mark Little (JIRA)

[ https://issues.jboss.org/browse/JBTM-1602?page=com.atlassian.jira.plugin.... ] Mark Little commented on JBTM-1602: ----------------------------------- I just noticed this change in the code and tracked it back to github (no JIRA associated with it, so I couldn't see what the issue was): try { Object syncObject = ((BasicAction.Current() == null) ? getMutex() : BasicAction.Current()); synchronized (this) { synchronized (getMutex()) { synchronized (syncObject) { I'm not sure why this change is in here, but need to check because it doesn't look right. Ignoring the fact that we now have 3 locks being acquired before the actual locksHeld lock, we're also potentially acquiring the same lock twice (syncObject could be getMutex())! > Determine why 4 locks acquired in propagate > ------------------------------------------- > > Key: JBTM-1602 > URL: https://issues.jboss.org/browse/JBTM-1602 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Mark Little > Assignee: Mark Little > -- 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, 8 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 March 2013