December 2015 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2517) Update the Narayana Release Process doc to include performance figures

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2517?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2517: -------------------------------- Component/s: Performance Testing > Update the Narayana Release Process doc to include performance figures > ---------------------------------------------------------------------- > > Key: JBTM-2517 > URL: https://issues.jboss.org/browse/JBTM-2517 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Performance Testing, Release Process > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Include a description in the NRP document of how to blog about performance figures when releasing a new version of Narayana -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2553) Investigate the test with byteman do not work with the jacoco

by Andrew Dinn (JIRA)

[ https://issues.jboss.org/browse/JBTM-2553?page=com.atlassian.jira.plugin.... ] Andrew Dinn commented on JBTM-2553: ----------------------------------- I looked further into this and found out why the Jacoco code is changing the start offset for 'this' and for the initial parameters in the local variable table. It happens because of the way they insert an entry probe at the start of the method. The entry probe is inserted immediately before processing the first of what may potentially be several labels which get processed prior to processing bytecode instructions. There is at least one label, the entry label, which is always processed just before the first instruction. If there is a local variable table with N method parameters then the entry label may be preceded by N other labels each of which identifies the start scope of one of the parameters. Injecting the entry probe before processing any of these parameter start labels means that there are 8 bytecodes in the code buffer when they do get processed hence why all the parameters are modified to have start offset 8. The obvious fix is to process the parameter start labels before injecting the probe e.g. generate the probe when the first real instruction is processed. However, that simple strategy won't work. The injection point needs to be picked precisely after processing the parameter labels but before processing the entry label. This ordering is critical in the case where the method starts with a while loop. In that case the entry label will be used as the target of the loop's backward branch (goto). Generating the probe after the entry label would mean that it would get re-executed on every loop iteration. This is not an easy problem to fix. It involves tracking visits to initial labels and matching them up with local var table entries. I'll see if I can find an easy way to do this that I can recommend to the Jacoco team. Until then this is going to remain borked. > Investigate the test with byteman do not work with the jacoco > ------------------------------------------------------------- > > Key: JBTM-2553 > URL: https://issues.jboss.org/browse/JBTM-2553 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Testing > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2544) RTS inbound bridge recovery does not work with JTS

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2544?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2544: -------------------------------- Fix Version/s: 5.later (was: 5.next) > RTS inbound bridge recovery does not work with JTS > -------------------------------------------------- > > Key: JBTM-2544 > URL: https://issues.jboss.org/browse/JBTM-2544 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.later > > > If JTS is enabled, crash scenario when system fails just before the commit does not complete correctly. Instead of being committed, resource is rolled back by XARecoveryModule. > In JTA case, XARecoveryModule does not find any XAResourceRecords and bridge recovery is handled by InboundBridgeRecoveryModule. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2569) If the JDBC store is unavailable it is possible for XAResources to be identified as orphans and rolled back

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2569?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2569: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > If the JDBC store is unavailable it is possible for XAResources to be identified as orphans and rolled back > ----------------------------------------------------------------------------------------------------------- > > Key: JBTM-2569 > URL: https://issues.jboss.org/browse/JBTM-2569 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.next > > > During investigation of https://issues.jboss.org/browse/JBEAP-1750 it was discovered that there exists an issue in XARecoveryModule where if the object store transaction log check throws an exception during orphan detection then the record is treated as if it does not have a log. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2544) RTS inbound bridge recovery does not work with JTS

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2544?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2544: -------------------------------- Forum Reference: https://developer.jboss.org/thread/266295 > RTS inbound bridge recovery does not work with JTS > -------------------------------------------------- > > Key: JBTM-2544 > URL: https://issues.jboss.org/browse/JBTM-2544 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > If JTS is enabled, crash scenario when system fails just before the commit does not complete correctly. Instead of being committed, resource is rolled back by XARecoveryModule. > In JTA case, XARecoveryModule does not find any XAResourceRecords and bridge recovery is handled by InboundBridgeRecoveryModule. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2409) XARecoveryModuleHelpersUnitTest hang

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2409?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2409: ----------------------------------- Attachment: hang.jstack > XARecoveryModuleHelpersUnitTest hang > ------------------------------------ > > Key: JBTM-2409 > URL: https://issues.jboss.org/browse/JBTM-2409 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Attachments: 32287.jstack, hang.jstack > > > The test checks that recovery helpers can be removed at the correct stages during recovery scans. The CI job http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/196 shows the hang. > The junit test thread: > - starts 2 threads that will remove a recovery helper > - triggers xaRecoveryModule.periodicWorkFirstPass() > - triggers xaRecoveryModule.periodicWorkSecondPass() > - joins with remover threads > The jstack output shows: > - the two threads in the process of removing a recovery helper and are waiting for the first pass to finish; > - the junit test thread is waiting to join with these two threads; > Since both recovery passes must have completed it looks like the remover threads weren't notified when the first pass completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2409) XARecoveryModuleHelpersUnitTest hang

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2409?page=com.atlassian.jira.plugin.... ] Michael Musgrove reopened JBTM-2409: ------------------------------------ stack trace of another hang attached > XARecoveryModuleHelpersUnitTest hang > ------------------------------------ > > Key: JBTM-2409 > URL: https://issues.jboss.org/browse/JBTM-2409 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Recovery > Affects Versions: 5.1.1 > Reporter: Michael Musgrove > Assignee: Tom Jenkinson > Attachments: 32287.jstack > > > The test checks that recovery helpers can be removed at the correct stages during recovery scans. The CI job http://albany.eng.hst.ams2.redhat.com/job/narayana-codeCoverage/196 shows the hang. > The junit test thread: > - starts 2 threads that will remove a recovery helper > - triggers xaRecoveryModule.periodicWorkFirstPass() > - triggers xaRecoveryModule.periodicWorkSecondPass() > - joins with remover threads > The jstack output shows: > - the two threads in the process of removing a recovery helper and are waiting for the first pass to finish; > - the junit test thread is waiting to join with these two threads; > Since both recovery passes must have completed it looks like the remover threads weren't notified when the first pass completed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2564) Quickstart tests failed on pure-ipv6 linux

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2564?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2564: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Quickstart tests failed on pure-ipv6 linux > ------------------------------------------ > > Key: JBTM-2564 > URL: https://issues.jboss.org/browse/JBTM-2564 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Environment: Pure IPv6 configured RHEL6 > Reporter: Hayk Hovsepyan > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > Some of JBossTS Quickstart tests fail on pure-IPv6 linux machine. > The failure is, that IIOP OPENJDK ORB Service can not be started, possibly because of configuration issue. > On dual-stack-IPv6 machines they pass. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 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 December 2015