May 2014 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2170) Jacoco failed to create QA code coverage report

by Gytis Trikleris (JIRA)

Gytis Trikleris created JBTM-2170: ------------------------------------- Summary: Jacoco failed to create QA code coverage report Key: JBTM-2170 URL: https://issues.jboss.org/browse/JBTM-2170 Project: JBoss Transaction Manager Issue Type: Bug Security Level: Public (Everyone can see) Components: Testing Reporter: Gytis Trikleris Assignee: Michael Musgrove Priority: Minor Fix For: 5.0.2 http://172.17.131.2/view/Narayana+BlackTie/job/narayana-codeCoverage/118 {code} BUILD SUCCESSFUL Total time: 510 minutes 46 seconds generating test coverage report Buildfile: /home/hudson/workspace/narayana-codeCoverage/qa/run-tests.xml jacoco-report: [jacoco:report] Loading execution data file /home/hudson/workspace/narayana-codeCoverage/qa/testoutput/jacoco-qa.exec BUILD FAILED /home/hudson/workspace/narayana-codeCoverage/qa/run-tests.xml:540: Error while creating report Total time: 8 seconds Buildfile: /home/hudson/workspace/narayana-codeCoverage/qa/run-tests.xml has-testoutput-output: testoutput.zip: [echo] archiving testoutput to testoutput-jacorb.zip [zip] Building zip: /home/hudson/workspace/narayana-codeCoverage/qa/testoutput-jacorb.zip BUILD SUCCESSFUL Total time: 9 seconds + rm -rf /home/hudson/.m2/repository/org/jboss/narayana + cd qa + ant -f run-tests.xml jacoco-report Buildfile: /home/hudson/workspace/narayana-codeCoverage/qa/run-tests.xml jacoco-report: [jacoco:report] Loading execution data file /home/hudson/workspace/narayana-codeCoverage/qa/testoutput/jacoco-qa.exec BUILD FAILED /home/hudson/workspace/narayana-codeCoverage/qa/run-tests.xml:540: Error while creating report Total time: 9 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Sending e-mails to: gtrikler(a)redhat.com Finished: FAILURE {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2169) Create some STM docs

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2169?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-2169: ---------------------------------------- We already have JBTM-2088 - I assume these two duplicate each other > Create some STM docs > -------------------- > > Key: JBTM-2169 > URL: https://issues.jboss.org/browse/JBTM-2169 > Project: JBoss Transaction Manager > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Documentation, STM > Affects Versions: 5.0.1 > Reporter: Mark Little > Assignee: Mark Little > > We don't have anything beyond some comments and readme files. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2164) CI app server rebase not working on Mac in narayana.sh

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2164?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-2164: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/655 > CI app server rebase not working on Mac in narayana.sh > ------------------------------------------------------ > > Key: JBTM-2164 > URL: https://issues.jboss.org/browse/JBTM-2164 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: BlackTie, Build System > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Critical > > Seems to be occurring since the app server updated to 8.1.0.Final-SNAPSHOT. It could be an issue with the grep/sed for the app server version. > {quote} > Building AS > First time checkout of AS7 > Cloning into jboss-as... > From https://github.com/wildfly/wildfly > * [new branch] 7.1 -> upstream/7.1 > * [new branch] 7.1-ignore -> upstream/7.1-ignore > * [new branch] master -> upstream/master > * [new branch] master-ignore -> upstream/master-ignore > * [new tag] 7.1.2-prerelease -> 7.1.2-prerelease > * [new tag] 7.1.2.Final -> 7.1.2.Final > * [new tag] 7.1.3.Beta1 -> 7.1.3.Beta1 > * [new tag] 7.2.0.Final -> 7.2.0.Final > * [new tag] 7.2.0.Final-prerelease1 -> 7.2.0.Final-prerelease1 > * [new tag] 8.0.0.Alpha1 -> 8.0.0.Alpha1 > * [new tag] 8.0.0.Alpha2 -> 8.0.0.Alpha2 > * [new tag] 8.0.0.Alpha3 -> 8.0.0.Alpha3 > * [new tag] 8.0.0.Alpha4 -> 8.0.0.Alpha4 > * [new tag] 8.0.0.Beta1 -> 8.0.0.Beta1 > * [new tag] 8.0.0.CR1 -> 8.0.0.CR1 > * [new tag] 8.0.0.Final -> 8.0.0.Final > * [new tag] 8.1.0.CR1 -> 8.1.0.CR1 > This is the JBoss-AS commit > 4e5271d07ace06e19745b933f9141f718bdce1b5 > From https://github.com/wildfly/wildfly > * branch master -> FETCH_HEAD > Current branch 5_BRANCH is up to date. > AS version is <version>8.1.0.Final-SNAPSHOT</version> > Need to upgrade the jboss-as.version in the narayana pom.xml to > Build step 'Execute shell' marked build as failure > Archiving artifacts > Sending e-mails to: ***** > Finished: FAILURE > {quote} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2169) Create some STM docs

by Mark Little (JIRA)

Mark Little created JBTM-2169: --------------------------------- Summary: Create some STM docs Key: JBTM-2169 URL: https://issues.jboss.org/browse/JBTM-2169 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation, STM Affects Versions: 5.0.1 Reporter: Mark Little Assignee: Mark Little We don't have anything beyond some comments and readme files. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2168) Consider changing some TXOJ warning messages to info or debug

by Mark Little (JIRA)

Mark Little created JBTM-2168: --------------------------------- Summary: Consider changing some TXOJ warning messages to info or debug Key: JBTM-2168 URL: https://issues.jboss.org/browse/JBTM-2168 Project: JBoss Transaction Manager Issue Type: Task Security Level: Public (Everyone can see) Components: STM, Transaction Core Affects Versions: 5.0.1 Reporter: Mark Little Assignee: Mark Little Priority: Minor Some warning messages in, say, LockManager for when lock conflicts occur should probably be reassigned as info, since we a) always fail safe, and b) return a status that indicates a lock conflict has happened. Hasn't been much of an issue to date, but the increase of multicore and Vert.x use could show these up a lot more. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2166) narayana-jts-all is not stored in .m2 repository, when built with narayana.sh

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2166?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2166: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done I had renamed one of the profiles. I have reverted that change. > narayana-jts-all is not stored in .m2 repository, when built with narayana.sh > ----------------------------------------------------------------------------- > > Key: JBTM-2166 > URL: https://issues.jboss.org/browse/JBTM-2166 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTS > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.0.2 > > > http://172.17.131.2/view/Narayana+BlackTie/job/narayana/508/ > My assumption is that it was caused by this commit, since it is the last one which modified narayana.sh: https://github.com/jbosstm/narayana/commit/947f384645151d5b9b0d9985aebc2d... -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1702: -------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/jbosstm/narayana/pull/300/files, https://github.com/jbosstm/narayana/pull/606, https://github.com/jbosstm/narayana/pull/652, https://github.com/jbosstm/narayana/pull/653 (was: https://github.com/jbosstm/narayana/pull/300/files, https://github.com/jbosstm/narayana/pull/606) Hi, I have pulled the required changes into the JTS variants. CI is running on this now. Please may I ask you to verify you are getting the behaviour you are expecting also. (its #653 for the 4.17 version) Many thanks, Tom > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2166) narayana-jts-all is not stored in .m2 repository, when built with narayana.sh

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2166?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-2166: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/651 > narayana-jts-all is not stored in .m2 repository, when built with narayana.sh > ----------------------------------------------------------------------------- > > Key: JBTM-2166 > URL: https://issues.jboss.org/browse/JBTM-2166 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JTS > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Blocker > Fix For: 5.0.2 > > > http://172.17.131.2/view/Narayana+BlackTie/job/narayana/508/ > My assumption is that it was caused by this commit, since it is the last one which modified narayana.sh: https://github.com/jbosstm/narayana/commit/947f384645151d5b9b0d9985aebc2d... -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1702) one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success

by Christian von Kutzleben (JIRA)

[ https://issues.jboss.org/browse/JBTM-1702?page=com.atlassian.jira.plugin.... ] Christian von Kutzleben reopened JBTM-1702: ------------------------------------------- Sorry, that I need to reopen this issue again: We're testing against EAP 6.1.1, where JBTM-1702 is partially fixed (if an XA_RB* error is thrown, then it works) However our client intends to use the JTS implementation rather than the JTA implementation of the Arjuna TM, and when we enabled jts (by adding <jts/> in the configuration) we encountered the original error (even with an XA_RB* error), even worse, the exception is not even logged (unlike with JTA mode)! (I added some System.out logging into our XAResource to verify, that indeed the very same exception is thrown). So I guess, the original mistake made it via cut'n'paste into both implementations and needs to be (fully) fixed for the respective JTS class as well. Thank you! Christian > one-phase optimization: XAException by XAResource swallowed and bean invocation falsely a success > ------------------------------------------------------------------------------------------------- > > Key: JBTM-1702 > URL: https://issues.jboss.org/browse/JBTM-1702 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Transaction Core > Affects Versions: 5.0.0.M2 > Reporter: Christian von Kutzleben > Assignee: Tom Jenkinson > Fix For: 4.17.18, 5.0.2 > > > We provide our own XAResource implementation for our database product, > in our unit testsuite we do also test common error conditions. > The error condition we test here is, that XAResource.end() throws an XAException with an XA_RBCOMMFAIL error code, this error code (by definition and also in our implementation) indicates an unilateral transaction rollback. > The expected behavior is, that when the TransactionManager invokes end() during it's commit procedure and sees an exception, that the transaction is considered as rolled-back and the bean client receives an exception, indicating the transaction failure. > The observed behavior is, that the bean client completes the bean method invocation successfully. Of course the transaction was rolled back by the database server and the subsequent bean invocations don't work correctly, because data assumed to be stored was actually not stored. > This error occurs if and only if the one-phase optimization is used, i.e. if > exactly one XAResource instance is enlisted with the TransactionManager. > If we enlist 2+ XAResource instances, then the one-phase optimization can't be used and the observed behavior is as expected, i.e. the bean client gets an exception, that the transaction could not be completed successfully. > The broken logic is contained in here (also see a complete stack trace below): > com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > Here the outcome was TwoPhaseOutcome.FINISH_ERROR but is mapped to ActionStatus.COMMITTED, this is clearly wrong for all XA_RB* error codes. > FIX suggestion: If there are cases, where this mapping is required, then instead of one FINISH_ERROR return value, two return values should be introduced, so that at least all XA_RB* error codes can be mapped properly to a transaction failure. > This is the complete stacktrace of our exception (logged immediately prior before it was thrown): > About to throw 1: com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost]. > com.versant.odbms.VersantXAException: Detach error: Network error on database [jpadb1@localhost]. > at com.versant.odbms.XAResourceImpl.getResult(XAResourceImpl.java:553) > at com.versant.odbms.XAResourceBase.detach(XAResourceBase.java:54) > at com.versant.odbms.XAResourceImpl.end(XAResourceImpl.java:278) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelOnePhaseCommit(XAResourceRecord.java:597) --> returns TwoPhaseOutcome.FINISH_ERROR (l.734) > at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2310) --> l.2339-2360: actionStatus = ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) --> returns ActionStatus.COMMITTED > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) --> l.1169 break, no exception > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2154) QA suite failure with db2 in jobs 71 and 72

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2154?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-2154: ---------------------------------------- We also had issues with the oracle instance due to insufficient connections. I increased the number of db2 connections from 200 to 1000 (db2 update dbm cfg using max_connections 1000 automatic) to see if it fixes the issue (the db2diag.log is 4GB so I didn't check to see if we had any connection errors there): > QA suite failure with db2 in jobs 71 and 72 > ------------------------------------------- > > Key: JBTM-2154 > URL: https://issues.jboss.org/browse/JBTM-2154 > Project: JBoss Transaction Manager > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Testing > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.0.2 > > Attachments: JTSRemote_TimeoutTest.tar > > > http://172.17.131.2/view/Narayana+BlackTie/job/narayana-jdbcobjectstore/7... -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 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 May 2014