March 2013 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-1209) XTS recovery tests failing due to a non-empty TXObjectStore after test complete

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1209?page=com.atlassian.jira.plugin.... ] Gytis Trikleris commented on JBTM-1209: --------------------------------------- http://172.17.131.2/view/Narayana+BlackTie/job/narayana/211 > XTS recovery tests failing due to a non-empty TXObjectStore after test complete > ------------------------------------------------------------------------------- > > Key: JBTM-1209 > URL: https://issues.jboss.org/browse/JBTM-1209 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Testing > Affects Versions: 5.0.0.M1 > Reporter: Paul Robinson > Assignee: Amos Feng > Fix For: 4.17.0, 5.0.0.M2 > > > See: http://172.17.131.2/view/Narayana+BlackTie/job/narayana-java7/411/console > Looking at http://172.17.131.2/job/narayana-java7/411/artifact/XTS/localjunit/crash-... you will see: > {code} > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:92) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.junit.Assert.assertTrue(Assert.java:54) > at com.arjuna.qa.junit.BaseCrashTest.tearDown(BaseCrashTest.java:105) > {code} > This assertion checks that the TXObjectStore is empty after the test completes. For the three tests that failed in this job, the log was not empty. > Looking at the end of http://172.17.131.2/job/narayana-java7/411/artifact/XTS/localjunit/crash-... shows you: > {code} > [0m[0m10:36:04,605 INFO [stdout] (Periodic Recovery) rule.debug{trace remove committed state} : removed committed transaction 0:ffffac118303:4e49dd0f:50110ed5:10 > [0m[0m10:36:04,605 INFO [stdout] (Periodic Recovery) rule.debug{trace remove committed state} : !!!killing JVM!!! > {code} > This suggests that the transaction log was removed. However, I'm not sure that the Byteman script checks that the participant record has also been removed. It's possible that the AS is being killed slightly too early, before the participant record is removed. We should check other scripts to see if they wait for both logs to be removed. > [JBTM-1208] should help debug this problem if we get it again. -- 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

1
0
0 / 0

[JBoss JIRA] (JBTM-1364) Migrate "REST-AT to JTA" bridge into REST-TX component

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1364?focusedWorklogId=12428932&page=... ] Gytis Trikleris logged work on JBTM-1364: ----------------------------------------- Author: Gytis Trikleris Created on: 24/Mar/13 5:00 PM Start Date: 24/Mar/13 5:00 PM Worklog Time Spent: 1 day, 2 hours Issue Time Tracking ------------------- Remaining Estimate: 2 days, 7 hours (was: 4 days, 1 hour) Time Spent: 2 days, 1 hour (was: 7 hours) Worklog Id: (was: 12428932) > Migrate "REST-AT to JTA" bridge into REST-TX component > ------------------------------------------------------ > > Key: JBTM-1364 > URL: https://issues.jboss.org/browse/JBTM-1364 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Demonstrator, REST, TxBridge > Reporter: Paul Robinson > Assignee: Gytis Trikleris > Labels: assign > Fix For: 5.0.0.M3 > > Original Estimate: 1 week > Time Spent: 2 days, 1 hour > Remaining Estimate: 2 days, 7 hours > > The task is to the work Gytis did on his internship and migrate it into the REST-TX project. > Tasks: > 1. Review the current solution looking for: > 1.1 Major issues that prevent an initial release > 1.2 Test coverage > 2. Make any required changes > 3. Merge into the REST-TX project > 4. Migrate the quickstarts accross > 5. Create a blog post > 5.1 Consider what the end user will need to do to use this technology. We may want to wait until REST-AT and this Bridge are shipped with a Narayana build of AS7. Otherwise the steps to get this working could be rather lengthy. -- 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

1
0
0 / 0

[JBoss JIRA] (JBTM-1211) Fix qa suite failure: org.jboss.jbossts.qa.junit.testgroup.TestGroup_jtsremote

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1211?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-1211: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/143, https://github.com/jbosstm/narayana/pull/144, https://github.com/jbosstm/narayana/pull/243 (was: https://github.com/jbosstm/narayana/pull/143, https://github.com/jbosstm/narayana/pull/144) > Fix qa suite failure: org.jboss.jbossts.qa.junit.testgroup.TestGroup_jtsremote > ------------------------------------------------------------------------------ > > Key: JBTM-1211 > URL: https://issues.jboss.org/browse/JBTM-1211 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTS, Testing, Transaction Core > Affects Versions: 4.16.4 > Reporter: Paul Robinson > Assignee: Michael Musgrove > Fix For: 4.17.4, 5.0.0.M3 > > Attachments: jbossts-narayana-java6-ipv6-dualstack.57.tar, jtsremote(1).zip, jtsremote.zip > > Original Estimate: 1 day > Remaining Estimate: 1 day > > See: http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-branch416-java6/232 > {code} > Running org.jboss.jbossts.qa.junit.testgroup.TestGroup_jtsremote > [junit] Tests run: 9, Failures: 1, Errors: 0, Time elapsed: 169.235 sec > {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, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1350) Deadlock in LockManager

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1350?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-1350: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/143, https://github.com/jbosstm/narayana/pull/144, https://github.com/jbosstm/narayana/pull/243 (was: https://github.com/jbosstm/narayana/pull/143, https://github.com/jbosstm/narayana/pull/144) > Deadlock in LockManager > ----------------------- > > Key: JBTM-1350 > URL: https://issues.jboss.org/browse/JBTM-1350 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 5.0.0.M1, 4.17.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.3, 5.0.0.M3 > > Attachments: deadlock_via_intrinsic_lock, deadlock_via_ServerNestedAction, jstack.16785 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > A deadlock can occur whilst calling LockManager.setlock if another thread tries to commit a transaction that has the same lock manager as a participant. The attached java stack dump, jstack.16785, (from test com.hp.mwtests.ts.jts.remote.hammer.DistributedHammer2) shows an example. It shows two threads interacting with a remote HammerObject: > - Thread 1 updates the remote object; > - Thread 2 commits a transaction that has the same HammerObject instance as a participant; > Thread 1 calls setlock on HammerObject which synchronizes on BasicAction.Current() and LockManager.locksHeldLockObject and then activates the object (which triggers an object load from the object store). The activate call tries to lock StateManager.mutex and this is where thread 1 deadlocks. > Meanwhile a commit request is issued which results in Thread 2 running at the same time thread 1 is calling activate. The commit asks HammerObject to prepare and commit. The participant commit asks HammerObject to release any locks it has held (LockManager.releaseAll). This call first tries to lock BasicAction.Current() which is null during commit time (since commit disassociates the transaction from the thread before committing the participants). Instead it locks StateManager.mutex which succeeds. Then it tries to lock LockManager.locksHeldLockObject and that is where Thread 2 deadlocks. > Note that the problem arises because Thread 2 gets null when it calls BasicAction.Current() and instead locks StateManager.mutex. If BasicAction.Current() was not null thread 2 would try to lock it but would not obtain the lock until thread 1 had completed the activate call and released BasicAction.Current() thus allowing thread 2 to continue as normal. -- 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

1
0
0 / 0

[JBoss JIRA] (JBTM-1350) Deadlock in LockManager

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-1350?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-1350: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Deadlock in LockManager > ----------------------- > > Key: JBTM-1350 > URL: https://issues.jboss.org/browse/JBTM-1350 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 5.0.0.M1, 4.17.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.0.0.M3, 4.17.3 > > Attachments: deadlock_via_intrinsic_lock, deadlock_via_ServerNestedAction, jstack.16785 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > A deadlock can occur whilst calling LockManager.setlock if another thread tries to commit a transaction that has the same lock manager as a participant. The attached java stack dump, jstack.16785, (from test com.hp.mwtests.ts.jts.remote.hammer.DistributedHammer2) shows an example. It shows two threads interacting with a remote HammerObject: > - Thread 1 updates the remote object; > - Thread 2 commits a transaction that has the same HammerObject instance as a participant; > Thread 1 calls setlock on HammerObject which synchronizes on BasicAction.Current() and LockManager.locksHeldLockObject and then activates the object (which triggers an object load from the object store). The activate call tries to lock StateManager.mutex and this is where thread 1 deadlocks. > Meanwhile a commit request is issued which results in Thread 2 running at the same time thread 1 is calling activate. The commit asks HammerObject to prepare and commit. The participant commit asks HammerObject to release any locks it has held (LockManager.releaseAll). This call first tries to lock BasicAction.Current() which is null during commit time (since commit disassociates the transaction from the thread before committing the participants). Instead it locks StateManager.mutex which succeeds. Then it tries to lock LockManager.locksHeldLockObject and that is where Thread 2 deadlocks. > Note that the problem arises because Thread 2 gets null when it calls BasicAction.Current() and instead locks StateManager.mutex. If BasicAction.Current() was not null thread 2 would try to lock it but would not obtain the lock until thread 1 had completed the activate call and released BasicAction.Current() thus allowing thread 2 to continue as normal. -- 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

1
0
0 / 0

[JBoss JIRA] (JBTM-1452) Distribution name of 4.17.x is narayana* rather than jbossts*

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1452?page=com.atlassian.jira.plugin.... ] Gytis Trikleris updated JBTM-1452: ---------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/jbosstm/narayana/pull/249 > Distribution name of 4.17.x is narayana* rather than jbossts* > ------------------------------------------------------------- > > Key: JBTM-1452 > URL: https://issues.jboss.org/browse/JBTM-1452 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Build System > Affects Versions: 4.17.3 > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 4.17.4 > > > See https://www.jboss.org/jbosstm/downloads/4_17_3_Final -- 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

1
0
0 / 0

[JBoss JIRA] (JBTM-1480) On using hornetq object store native libraries are loaded automatically - it should be configurable

by Ivo Studensky (JIRA)

[ https://issues.jboss.org/browse/JBTM-1480?page=com.atlassian.jira.plugin.... ] Ivo Studensky updated JBTM-1480: -------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/240, https://github.com/jbosstm/narayana/pull/242, https://github.com/jbosstm/documentation/pull/10, https://github.com/jbosstm/documentation/pull/11 (was: https://github.com/jbosstm/narayana/pull/240, https://github.com/jbosstm/narayana/pull/242) Adding two another PRs for a small fix in the docs. > On using hornetq object store native libraries are loaded automatically - it should be configurable > --------------------------------------------------------------------------------------------------- > > Key: JBTM-1480 > URL: https://issues.jboss.org/browse/JBTM-1480 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Configuration > Affects Versions: 4.17.3, 5.0.0.M2 > Reporter: Ondřej Chaloupka > Assignee: Ivo Studensky > Fix For: 4.17.4, 5.0.0.M3 > > > Currently when HornetQ implementation of object store is used and native libraries (AIO) are available the native are used without user's explicit request. > It was decided that user should have possibility to define whether the native libraries will be used or not. -- 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

1
0
0 / 0

[JBoss JIRA] (JBTM-1452) Distribution name of 4.17.x is narayana* rather than jbossts*

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1452?page=com.atlassian.jira.plugin.... ] Work on JBTM-1452 started by Gytis Trikleris. > Distribution name of 4.17.x is narayana* rather than jbossts* > ------------------------------------------------------------- > > Key: JBTM-1452 > URL: https://issues.jboss.org/browse/JBTM-1452 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Build System > Affects Versions: 4.17.3 > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 4.17.4 > > > See https://www.jboss.org/jbosstm/downloads/4_17_3_Final -- 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

1
0
0 / 0

[JBoss JIRA] (JBTM-1209) XTS recovery tests failing due to a non-empty TXObjectStore after test complete

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-1209?page=com.atlassian.jira.plugin.... ] Gytis Trikleris commented on JBTM-1209: --------------------------------------- http://172.17.131.2/view/Narayana+BlackTie/job/narayana/209 > XTS recovery tests failing due to a non-empty TXObjectStore after test complete > ------------------------------------------------------------------------------- > > Key: JBTM-1209 > URL: https://issues.jboss.org/browse/JBTM-1209 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Testing > Affects Versions: 5.0.0.M1 > Reporter: Paul Robinson > Assignee: Amos Feng > Fix For: 4.17.0, 5.0.0.M2 > > > See: http://172.17.131.2/view/Narayana+BlackTie/job/narayana-java7/411/console > Looking at http://172.17.131.2/job/narayana-java7/411/artifact/XTS/localjunit/crash-... you will see: > {code} > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:92) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.junit.Assert.assertTrue(Assert.java:54) > at com.arjuna.qa.junit.BaseCrashTest.tearDown(BaseCrashTest.java:105) > {code} > This assertion checks that the TXObjectStore is empty after the test completes. For the three tests that failed in this job, the log was not empty. > Looking at the end of http://172.17.131.2/job/narayana-java7/411/artifact/XTS/localjunit/crash-... shows you: > {code} > [0m[0m10:36:04,605 INFO [stdout] (Periodic Recovery) rule.debug{trace remove committed state} : removed committed transaction 0:ffffac118303:4e49dd0f:50110ed5:10 > [0m[0m10:36:04,605 INFO [stdout] (Periodic Recovery) rule.debug{trace remove committed state} : !!!killing JVM!!! > {code} > This suggests that the transaction log was removed. However, I'm not sure that the Byteman script checks that the participant record has also been removed. It's possible that the AS is being killed slightly too early, before the participant record is removed. We should check other scripts to see if they wait for both logs to be removed. > [JBTM-1208] should help debug this problem if we get it again. -- 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

1
0
0 / 0

[JBoss JIRA] (JBTM-1537) blacktie-quickstarts-integration1-xatmi_adapter is missing M3 dependencies

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1537?page=com.atlassian.jira.plugin.... ] Tom Jenkinson resolved JBTM-1537. --------------------------------- Resolution: Done > blacktie-quickstarts-integration1-xatmi_adapter is missing M3 dependencies > -------------------------------------------------------------------------- > > Key: JBTM-1537 > URL: https://issues.jboss.org/browse/JBTM-1537 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: BlackTie > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.0.0.M3 > > > See: http://172.17.131.2/job/btny-narayana-quickstarts-taconic/244 -- 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

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