From issues at jboss.org Thu Sep 1 10:06:00 2016 From: issues at jboss.org (Zefa Guan (JIRA)) Date: Thu, 1 Sep 2016 10:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2746) facing performane issue when setup narayana JTA and txbridge out of JBoss In-Reply-To: References: Message-ID: Zefa Guan created JBTM-2746: ------------------------------- Summary: facing performane issue when setup narayana JTA and txbridge out of JBoss Key: JBTM-2746 URL: https://issues.jboss.org/browse/JBTM-2746 Project: JBoss Transaction Manager Issue Type: Enhancement Reporter: Zefa Guan when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; servlet client - localhost:8081/user?action=add | -------------------------------------------------------------- ServiceA Tomcat Narayana JTA Webservie - localhost:8082/user?action=add -------------------------------------------------------------- | txbridge | -------------------------------------------------------------- ServiceB Tomcat Narayana JTA Webservie - localhost:8083/user?action=add -------------------------------------------------------------- | txbridge | -------------------------------------------------------------- ServiceB Tomcat Narayana JTA -------------------------------------------------------------- -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 1 10:06:00 2016 From: issues at jboss.org (Zefa Guan (JIRA)) Date: Thu, 1 Sep 2016 10:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2746) facing performane issue when setup narayana JTA and txbridge out of JBoss In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zefa Guan updated JBTM-2746: ---------------------------- Description: when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; servlet client - localhost:8081/user?action=add || -------------------------------------------------------------- ServiceA Tomcat Narayana JTA Webservie - localhost:8082/user?action=add -------------------------------------------------------------- || txbridge || -------------------------------------------------------------- ServiceB Tomcat Narayana JTA Webservie - localhost:8083/user?action=add -------------------------------------------------------------- || txbridge || -------------------------------------------------------------- ServiceB Tomcat Narayana JTA -------------------------------------------------------------- was: when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; servlet client - localhost:8081/user?action=add | -------------------------------------------------------------- ServiceA Tomcat Narayana JTA Webservie - localhost:8082/user?action=add -------------------------------------------------------------- | txbridge | -------------------------------------------------------------- ServiceB Tomcat Narayana JTA Webservie - localhost:8083/user?action=add -------------------------------------------------------------- | txbridge | -------------------------------------------------------------- ServiceB Tomcat Narayana JTA -------------------------------------------------------------- > facing performane issue when setup narayana JTA and txbridge out of JBoss > ------------------------------------------------------------------------- > > Key: JBTM-2746 > URL: https://issues.jboss.org/browse/JBTM-2746 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Zefa Guan > > when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; > servlet client - localhost:8081/user?action=add > || > -------------------------------------------------------------- > ServiceA Tomcat > Narayana JTA > Webservie - localhost:8082/user?action=add > -------------------------------------------------------------- > || > txbridge > || > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > Webservie - localhost:8083/user?action=add > -------------------------------------------------------------- > || > txbridge > || > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > -------------------------------------------------------------- -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 1 10:07:00 2016 From: issues at jboss.org (Zefa Guan (JIRA)) Date: Thu, 1 Sep 2016 10:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2746) facing performane issue when setup narayana JTA and txbridge out of JBoss In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zefa Guan updated JBTM-2746: ---------------------------- Description: when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; {code} servlet client - localhost:8081/user?action=add | -------------------------------------------------------------- ServiceA Tomcat Narayana JTA Webservie - localhost:8082/user?action=add -------------------------------------------------------------- | txbridge | -------------------------------------------------------------- ServiceB Tomcat Narayana JTA Webservie - localhost:8083/user?action=add -------------------------------------------------------------- | txbridge | -------------------------------------------------------------- ServiceB Tomcat Narayana JTA -------------------------------------------------------------- {code} was: when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; servlet client - localhost:8081/user?action=add || -------------------------------------------------------------- ServiceA Tomcat Narayana JTA Webservie - localhost:8082/user?action=add -------------------------------------------------------------- || txbridge || -------------------------------------------------------------- ServiceB Tomcat Narayana JTA Webservie - localhost:8083/user?action=add -------------------------------------------------------------- || txbridge || -------------------------------------------------------------- ServiceB Tomcat Narayana JTA -------------------------------------------------------------- > facing performane issue when setup narayana JTA and txbridge out of JBoss > ------------------------------------------------------------------------- > > Key: JBTM-2746 > URL: https://issues.jboss.org/browse/JBTM-2746 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Zefa Guan > > when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; > {code} > servlet client - localhost:8081/user?action=add > | > -------------------------------------------------------------- > ServiceA Tomcat > Narayana JTA > Webservie - localhost:8082/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > Webservie - localhost:8083/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > -------------------------------------------------------------- > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 1 10:14:00 2016 From: issues at jboss.org (Zefa Guan (JIRA)) Date: Thu, 1 Sep 2016 10:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2746) facing performane issue when setup narayana JTA and txbridge out of JBoss In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zefa Guan updated JBTM-2746: ---------------------------- Description: when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; 1) running 3 tomcat instances 2) A call B via WS 3) B call C via WS 4) when 100 - 200 GET query from " http://localhost:8081/user?action=add " via Service A, all 3 tomcat got stuck for a while then raise exception with attached logs --------------------------------------------- the reason may cause by race condition/socket timeout/exceed limits, will need to reproduce and research more at the beginning I thought it was caused by DB resource locking failed but after I commented out all DB access, the problem still there put all my code to https://github.com/JonkeyGuan/txbridgeInTomcat8 for reproducing and reference {code} servlet client - localhost:8081/user?action=add | -------------------------------------------------------------- ServiceA Tomcat Narayana JTA Webservie - localhost:8082/user?action=add -------------------------------------------------------------- | txbridge | -------------------------------------------------------------- ServiceB Tomcat Narayana JTA Webservie - localhost:8083/user?action=add -------------------------------------------------------------- | txbridge | -------------------------------------------------------------- ServiceB Tomcat Narayana JTA -------------------------------------------------------------- {code} was: when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; {code} servlet client - localhost:8081/user?action=add | -------------------------------------------------------------- ServiceA Tomcat Narayana JTA Webservie - localhost:8082/user?action=add -------------------------------------------------------------- | txbridge | -------------------------------------------------------------- ServiceB Tomcat Narayana JTA Webservie - localhost:8083/user?action=add -------------------------------------------------------------- | txbridge | -------------------------------------------------------------- ServiceB Tomcat Narayana JTA -------------------------------------------------------------- {code} > facing performane issue when setup narayana JTA and txbridge out of JBoss > ------------------------------------------------------------------------- > > Key: JBTM-2746 > URL: https://issues.jboss.org/browse/JBTM-2746 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Zefa Guan > > when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; > 1) running 3 tomcat instances > 2) A call B via WS > 3) B call C via WS > 4) when 100 - 200 GET query from " http://localhost:8081/user?action=add " via Service A, all 3 tomcat got stuck for a while then raise exception with attached logs > --------------------------------------------- > the reason may cause by race condition/socket timeout/exceed limits, will need to reproduce and research more > at the beginning I thought it was caused by DB resource locking failed but after I commented out all DB access, the problem still there > put all my code to https://github.com/JonkeyGuan/txbridgeInTomcat8 for reproducing and reference > {code} > servlet client - localhost:8081/user?action=add > | > -------------------------------------------------------------- > ServiceA Tomcat > Narayana JTA > Webservie - localhost:8082/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > Webservie - localhost:8083/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > -------------------------------------------------------------- > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 1 10:19:00 2016 From: issues at jboss.org (Zefa Guan (JIRA)) Date: Thu, 1 Sep 2016 10:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2746) facing performane issue when setup narayana JTA and txbridge out of JBoss In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zefa Guan updated JBTM-2746: ---------------------------- Attachment: ServiceC_logs.zip ServiceB_logs.zip ServiceA_logs.zip Attached tomcat log A, B and C > facing performane issue when setup narayana JTA and txbridge out of JBoss > ------------------------------------------------------------------------- > > Key: JBTM-2746 > URL: https://issues.jboss.org/browse/JBTM-2746 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Zefa Guan > Attachments: ServiceA_logs.zip, ServiceB_logs.zip, ServiceC_logs.zip > > > when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; > 1) running 3 tomcat instances > 2) A call B via WS > 3) B call C via WS > 4) when 100 - 200 GET query from " http://localhost:8081/user?action=add " via Service A, all 3 tomcat got stuck for a while then raise exception with attached logs > --------------------------------------------- > the reason may cause by race condition/socket timeout/exceed limits, will need to reproduce and research more > at the beginning I thought it was caused by DB resource locking failed but after I commented out all DB access, the problem still there > put all my code to https://github.com/JonkeyGuan/txbridgeInTomcat8 for reproducing and reference > {code} > servlet client - localhost:8081/user?action=add > | > -------------------------------------------------------------- > ServiceA Tomcat > Narayana JTA > Webservie - localhost:8082/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > Webservie - localhost:8083/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > -------------------------------------------------------------- > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 1 10:21:00 2016 From: issues at jboss.org (Zefa Guan (JIRA)) Date: Thu, 1 Sep 2016 10:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2746) facing performane issue when setup narayana JTA and txbridge out of JBoss In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zefa Guan updated JBTM-2746: ---------------------------- Description: when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; 1) running 3 tomcat instances 2) A call B via WS 3) B call C via WS 4) when 100 - 200 GET query from " http://localhost:8081/user?action=add " via Service A, all 3 tomcat got stuck for a while then raise exception with attached logs {code} servlet client - localhost:8081/user?action=add | -------------------------------------------------------------- ServiceA Tomcat Narayana JTA Webservie - localhost:8082/user?action=add -------------------------------------------------------------- | txbridge | -------------------------------------------------------------- ServiceB Tomcat Narayana JTA Webservie - localhost:8083/user?action=add -------------------------------------------------------------- | txbridge | -------------------------------------------------------------- ServiceB Tomcat Narayana JTA -------------------------------------------------------------- {code} --------------------------------------------- this may caused by race condition/socket timeout/exceed limits, will need to reproduce and research more; at the beginning I thought it was caused by DB resource locking failed but after I commented out all DB access, the problem still there put all my code to https://github.com/JonkeyGuan/txbridgeInTomcat8 for reproducing and reference was: when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; 1) running 3 tomcat instances 2) A call B via WS 3) B call C via WS 4) when 100 - 200 GET query from " http://localhost:8081/user?action=add " via Service A, all 3 tomcat got stuck for a while then raise exception with attached logs --------------------------------------------- the reason may cause by race condition/socket timeout/exceed limits, will need to reproduce and research more at the beginning I thought it was caused by DB resource locking failed but after I commented out all DB access, the problem still there put all my code to https://github.com/JonkeyGuan/txbridgeInTomcat8 for reproducing and reference {code} servlet client - localhost:8081/user?action=add | -------------------------------------------------------------- ServiceA Tomcat Narayana JTA Webservie - localhost:8082/user?action=add -------------------------------------------------------------- | txbridge | -------------------------------------------------------------- ServiceB Tomcat Narayana JTA Webservie - localhost:8083/user?action=add -------------------------------------------------------------- | txbridge | -------------------------------------------------------------- ServiceB Tomcat Narayana JTA -------------------------------------------------------------- {code} > facing performane issue when setup narayana JTA and txbridge out of JBoss > ------------------------------------------------------------------------- > > Key: JBTM-2746 > URL: https://issues.jboss.org/browse/JBTM-2746 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Zefa Guan > Attachments: ServiceA_logs.zip, ServiceB_logs.zip, ServiceC_logs.zip > > > when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; > 1) running 3 tomcat instances > 2) A call B via WS > 3) B call C via WS > 4) when 100 - 200 GET query from " http://localhost:8081/user?action=add " via Service A, all 3 tomcat got stuck for a while then raise exception with attached logs > {code} > servlet client - localhost:8081/user?action=add > | > -------------------------------------------------------------- > ServiceA Tomcat > Narayana JTA > Webservie - localhost:8082/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > Webservie - localhost:8083/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > -------------------------------------------------------------- > {code} > --------------------------------------------- > this may caused by race condition/socket timeout/exceed limits, will need to reproduce and research more; > at the beginning I thought it was caused by DB resource locking failed but after I commented out all DB access, the problem still there > put all my code to https://github.com/JonkeyGuan/txbridgeInTomcat8 for reproducing and reference -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 1 10:26:00 2016 From: issues at jboss.org (Zefa Guan (JIRA)) Date: Thu, 1 Sep 2016 10:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2746) facing performane issue when setup narayana JTA and txbridge out of JBoss In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zefa Guan updated JBTM-2746: ---------------------------- Description: when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; 1) running 3 tomcat instances 2) A call B via WS 3) B call C via WS 4) when 100 - 200 GET query from " http://localhost:8081/user?action=add " via Service A, all 3 tomcat got stuck for a while then raise exception with attached logs sth similar with quickstart example but no EJB and out of JBoss from https://github.com/jbosstm/quickstart/tree/master/XTS ================================================== WS-AT to JTA (Multi Hop) This example demonstrates a JTA client that invokes a remote EJB over Web services. The JTA transaction is distributed to the remote EJB using WS-AtomicTransaction. The service also acts as a client to a second service. Again using WS-AT to distribute the transaction over Web services. ================================================== {code} servlet client - localhost:8081/user?action=add | -------------------------------------------------------------- ServiceA Tomcat Narayana JTA Webservie - localhost:8082/user?action=add -------------------------------------------------------------- | txbridge | -------------------------------------------------------------- ServiceB Tomcat Narayana JTA Webservie - localhost:8083/user?action=add -------------------------------------------------------------- | txbridge | -------------------------------------------------------------- ServiceB Tomcat Narayana JTA -------------------------------------------------------------- {code} --------------------------------------------- this may caused by race condition/socket timeout/exceed limits, will need to reproduce and research more; at the beginning I thought it was caused by DB resource locking failed but after I commented out all DB access, the problem still there put all my code to https://github.com/JonkeyGuan/txbridgeInTomcat8 for reproducing and reference was: when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; 1) running 3 tomcat instances 2) A call B via WS 3) B call C via WS 4) when 100 - 200 GET query from " http://localhost:8081/user?action=add " via Service A, all 3 tomcat got stuck for a while then raise exception with attached logs {code} servlet client - localhost:8081/user?action=add | -------------------------------------------------------------- ServiceA Tomcat Narayana JTA Webservie - localhost:8082/user?action=add -------------------------------------------------------------- | txbridge | -------------------------------------------------------------- ServiceB Tomcat Narayana JTA Webservie - localhost:8083/user?action=add -------------------------------------------------------------- | txbridge | -------------------------------------------------------------- ServiceB Tomcat Narayana JTA -------------------------------------------------------------- {code} --------------------------------------------- this may caused by race condition/socket timeout/exceed limits, will need to reproduce and research more; at the beginning I thought it was caused by DB resource locking failed but after I commented out all DB access, the problem still there put all my code to https://github.com/JonkeyGuan/txbridgeInTomcat8 for reproducing and reference > facing performane issue when setup narayana JTA and txbridge out of JBoss > ------------------------------------------------------------------------- > > Key: JBTM-2746 > URL: https://issues.jboss.org/browse/JBTM-2746 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Zefa Guan > Attachments: ServiceA_logs.zip, ServiceB_logs.zip, ServiceC_logs.zip > > > when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; > 1) running 3 tomcat instances > 2) A call B via WS > 3) B call C via WS > 4) when 100 - 200 GET query from " http://localhost:8081/user?action=add " via Service A, all 3 tomcat got stuck for a while then raise exception with attached logs > sth similar with quickstart example but no EJB and out of JBoss from https://github.com/jbosstm/quickstart/tree/master/XTS > ================================================== > WS-AT to JTA (Multi Hop) > This example demonstrates a JTA client that invokes a remote EJB over Web services. The JTA transaction is distributed to the remote EJB using WS-AtomicTransaction. The service also acts as a client to a second service. Again using WS-AT to distribute the transaction over Web services. > ================================================== > {code} > servlet client - localhost:8081/user?action=add > | > -------------------------------------------------------------- > ServiceA Tomcat > Narayana JTA > Webservie - localhost:8082/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > Webservie - localhost:8083/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > -------------------------------------------------------------- > {code} > --------------------------------------------- > this may caused by race condition/socket timeout/exceed limits, will need to reproduce and research more; > at the beginning I thought it was caused by DB resource locking failed but after I commented out all DB access, the problem still there > put all my code to https://github.com/JonkeyGuan/txbridgeInTomcat8 for reproducing and reference -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 1 10:27:00 2016 From: issues at jboss.org (Zefa Guan (JIRA)) Date: Thu, 1 Sep 2016 10:27:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2746) facing performane issue when setup narayana JTA and txbridge out of JBoss In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zefa Guan updated JBTM-2746: ---------------------------- Affects Version/s: 5.3.4.Final > facing performane issue when setup narayana JTA and txbridge out of JBoss > ------------------------------------------------------------------------- > > Key: JBTM-2746 > URL: https://issues.jboss.org/browse/JBTM-2746 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Affects Versions: 5.3.4.Final > Reporter: Zefa Guan > Attachments: ServiceA_logs.zip, ServiceB_logs.zip, ServiceC_logs.zip > > > when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; > 1) running 3 tomcat instances > 2) A call B via WS > 3) B call C via WS > 4) when 100 - 200 GET query from " http://localhost:8081/user?action=add " via Service A, all 3 tomcat got stuck for a while then raise exception with attached logs > sth similar with quickstart example but no EJB and out of JBoss from https://github.com/jbosstm/quickstart/tree/master/XTS > ================================================== > WS-AT to JTA (Multi Hop) > This example demonstrates a JTA client that invokes a remote EJB over Web services. The JTA transaction is distributed to the remote EJB using WS-AtomicTransaction. The service also acts as a client to a second service. Again using WS-AT to distribute the transaction over Web services. > ================================================== > {code} > servlet client - localhost:8081/user?action=add > | > -------------------------------------------------------------- > ServiceA Tomcat > Narayana JTA > Webservie - localhost:8082/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > Webservie - localhost:8083/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > -------------------------------------------------------------- > {code} > --------------------------------------------- > this may caused by race condition/socket timeout/exceed limits, will need to reproduce and research more; > at the beginning I thought it was caused by DB resource locking failed but after I commented out all DB access, the problem still there > put all my code to https://github.com/JonkeyGuan/txbridgeInTomcat8 for reproducing and reference -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 1 10:27:00 2016 From: issues at jboss.org (Zefa Guan (JIRA)) Date: Thu, 1 Sep 2016 10:27:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2746) facing performane issue when setup narayana JTA and txbridge out of JBoss In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zefa Guan updated JBTM-2746: ---------------------------- Component/s: JTA TxBridge XTS > facing performane issue when setup narayana JTA and txbridge out of JBoss > ------------------------------------------------------------------------- > > Key: JBTM-2746 > URL: https://issues.jboss.org/browse/JBTM-2746 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA, TxBridge, XTS > Affects Versions: 5.3.4.Final > Reporter: Zefa Guan > Attachments: ServiceA_logs.zip, ServiceB_logs.zip, ServiceC_logs.zip > > > when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; > 1) running 3 tomcat instances > 2) A call B via WS > 3) B call C via WS > 4) when 100 - 200 GET query from " http://localhost:8081/user?action=add " via Service A, all 3 tomcat got stuck for a while then raise exception with attached logs > sth similar with quickstart example but no EJB and out of JBoss from https://github.com/jbosstm/quickstart/tree/master/XTS > ================================================== > WS-AT to JTA (Multi Hop) > This example demonstrates a JTA client that invokes a remote EJB over Web services. The JTA transaction is distributed to the remote EJB using WS-AtomicTransaction. The service also acts as a client to a second service. Again using WS-AT to distribute the transaction over Web services. > ================================================== > {code} > servlet client - localhost:8081/user?action=add > | > -------------------------------------------------------------- > ServiceA Tomcat > Narayana JTA > Webservie - localhost:8082/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > Webservie - localhost:8083/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > -------------------------------------------------------------- > {code} > --------------------------------------------- > this may caused by race condition/socket timeout/exceed limits, will need to reproduce and research more; > at the beginning I thought it was caused by DB resource locking failed but after I commented out all DB access, the problem still there > put all my code to https://github.com/JonkeyGuan/txbridgeInTomcat8 for reproducing and reference -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 1 10:41:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 1 Sep 2016 10:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2746) facing performane issue when setup narayana JTA and txbridge out of JBoss In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13287542#comment-13287542 ] Tom Jenkinson commented on JBTM-2746: ------------------------------------- Thanks for the report, normally we would ask that you open a discussion over here first: https://developer.jboss.org/en/jbosstm/content?filterID=contentstatus%5bpublished%5d~objecttype~objecttype%5bthread%5d I will leave this open for now but please create a discussion (and link to this issue). > facing performane issue when setup narayana JTA and txbridge out of JBoss > ------------------------------------------------------------------------- > > Key: JBTM-2746 > URL: https://issues.jboss.org/browse/JBTM-2746 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA, TxBridge, XTS > Affects Versions: 5.3.4.Final > Reporter: Zefa Guan > Attachments: ServiceA_logs.zip, ServiceB_logs.zip, ServiceC_logs.zip > > > when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; > 1) running 3 tomcat instances > 2) A call B via WS > 3) B call C via WS > 4) when 100 - 200 GET query from " http://localhost:8081/user?action=add " via Service A, all 3 tomcat got stuck for a while then raise exception with attached logs > sth similar with quickstart example but no EJB and out of JBoss from https://github.com/jbosstm/quickstart/tree/master/XTS > ================================================== > WS-AT to JTA (Multi Hop) > This example demonstrates a JTA client that invokes a remote EJB over Web services. The JTA transaction is distributed to the remote EJB using WS-AtomicTransaction. The service also acts as a client to a second service. Again using WS-AT to distribute the transaction over Web services. > ================================================== > {code} > servlet client - localhost:8081/user?action=add > | > -------------------------------------------------------------- > ServiceA Tomcat > Narayana JTA > Webservie - localhost:8082/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > Webservie - localhost:8083/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > -------------------------------------------------------------- > {code} > --------------------------------------------- > this may caused by race condition/socket timeout/exceed limits, will need to reproduce and research more; > at the beginning I thought it was caused by DB resource locking failed but after I commented out all DB access, the problem still there > put all my code to https://github.com/JonkeyGuan/txbridgeInTomcat8 for reproducing and reference -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 1 10:41:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 1 Sep 2016 10:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2746) facing performane issue when setup narayana JTA and txbridge out of JBoss In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2746: ----------------------------------- Assignee: Gytis Trikleris > facing performane issue when setup narayana JTA and txbridge out of JBoss > ------------------------------------------------------------------------- > > Key: JBTM-2746 > URL: https://issues.jboss.org/browse/JBTM-2746 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA, TxBridge, XTS > Affects Versions: 5.3.4.Final > Reporter: Zefa Guan > Assignee: Gytis Trikleris > Attachments: ServiceA_logs.zip, ServiceB_logs.zip, ServiceC_logs.zip > > > when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; > 1) running 3 tomcat instances > 2) A call B via WS > 3) B call C via WS > 4) when 100 - 200 GET query from " http://localhost:8081/user?action=add " via Service A, all 3 tomcat got stuck for a while then raise exception with attached logs > sth similar with quickstart example but no EJB and out of JBoss from https://github.com/jbosstm/quickstart/tree/master/XTS > ================================================== > WS-AT to JTA (Multi Hop) > This example demonstrates a JTA client that invokes a remote EJB over Web services. The JTA transaction is distributed to the remote EJB using WS-AtomicTransaction. The service also acts as a client to a second service. Again using WS-AT to distribute the transaction over Web services. > ================================================== > {code} > servlet client - localhost:8081/user?action=add > | > -------------------------------------------------------------- > ServiceA Tomcat > Narayana JTA > Webservie - localhost:8082/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > Webservie - localhost:8083/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > -------------------------------------------------------------- > {code} > --------------------------------------------- > this may caused by race condition/socket timeout/exceed limits, will need to reproduce and research more; > at the beginning I thought it was caused by DB resource locking failed but after I commented out all DB access, the problem still there > put all my code to https://github.com/JonkeyGuan/txbridgeInTomcat8 for reproducing and reference -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 1 10:46:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 1 Sep 2016 10:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2747) Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2747: ----------------------------------- Summary: Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions Key: JBTM-2747 URL: https://issues.jboss.org/browse/JBTM-2747 Project: JBoss Transaction Manager Issue Type: Task Components: Testing Reporter: Tom Jenkinson Fix For: 5.next The previous example relied upon the "transport" piece maintaining a list of root transactions it had seen. It is actually possible to use the existing list from the TransactionImple -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 1 10:54:00 2016 From: issues at jboss.org (Zefa Guan (JIRA)) Date: Thu, 1 Sep 2016 10:54:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2746) facing performane issue when setup narayana JTA and txbridge out of JBoss In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13287552#comment-13287552 ] Zefa Guan commented on JBTM-2746: --------------------------------- sure, post https://developer.jboss.org/message/962385#962385 > facing performane issue when setup narayana JTA and txbridge out of JBoss > ------------------------------------------------------------------------- > > Key: JBTM-2746 > URL: https://issues.jboss.org/browse/JBTM-2746 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA, TxBridge, XTS > Affects Versions: 5.3.4.Final > Reporter: Zefa Guan > Assignee: Gytis Trikleris > Attachments: ServiceA_logs.zip, ServiceB_logs.zip, ServiceC_logs.zip > > > when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; > 1) running 3 tomcat instances > 2) A call B via WS > 3) B call C via WS > 4) when 100 - 200 GET query from " http://localhost:8081/user?action=add " via Service A, all 3 tomcat got stuck for a while then raise exception with attached logs > sth similar with quickstart example but no EJB and out of JBoss from https://github.com/jbosstm/quickstart/tree/master/XTS > ================================================== > WS-AT to JTA (Multi Hop) > This example demonstrates a JTA client that invokes a remote EJB over Web services. The JTA transaction is distributed to the remote EJB using WS-AtomicTransaction. The service also acts as a client to a second service. Again using WS-AT to distribute the transaction over Web services. > ================================================== > {code} > servlet client - localhost:8081/user?action=add > | > -------------------------------------------------------------- > ServiceA Tomcat > Narayana JTA > Webservie - localhost:8082/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > Webservie - localhost:8083/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > -------------------------------------------------------------- > {code} > --------------------------------------------- > this may caused by race condition/socket timeout/exceed limits, will need to reproduce and research more; > at the beginning I thought it was caused by DB resource locking failed but after I commented out all DB access, the problem still there > put all my code to https://github.com/JonkeyGuan/txbridgeInTomcat8 for reproducing and reference -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 1 10:57:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 1 Sep 2016 10:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2746) facing performane issue when setup narayana JTA and txbridge out of JBoss In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13287553#comment-13287553 ] Tom Jenkinson commented on JBTM-2746: ------------------------------------- Thanks! > facing performane issue when setup narayana JTA and txbridge out of JBoss > ------------------------------------------------------------------------- > > Key: JBTM-2746 > URL: https://issues.jboss.org/browse/JBTM-2746 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA, TxBridge, XTS > Affects Versions: 5.3.4.Final > Reporter: Zefa Guan > Assignee: Gytis Trikleris > Attachments: ServiceA_logs.zip, ServiceB_logs.zip, ServiceC_logs.zip > > > when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario; > 1) running 3 tomcat instances > 2) A call B via WS > 3) B call C via WS > 4) when 100 - 200 GET query from " http://localhost:8081/user?action=add " via Service A, all 3 tomcat got stuck for a while then raise exception with attached logs > sth similar with quickstart example but no EJB and out of JBoss from https://github.com/jbosstm/quickstart/tree/master/XTS > ================================================== > WS-AT to JTA (Multi Hop) > This example demonstrates a JTA client that invokes a remote EJB over Web services. The JTA transaction is distributed to the remote EJB using WS-AtomicTransaction. The service also acts as a client to a second service. Again using WS-AT to distribute the transaction over Web services. > ================================================== > {code} > servlet client - localhost:8081/user?action=add > | > -------------------------------------------------------------- > ServiceA Tomcat > Narayana JTA > Webservie - localhost:8082/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > Webservie - localhost:8083/user?action=add > -------------------------------------------------------------- > | > txbridge > | > -------------------------------------------------------------- > ServiceB Tomcat > Narayana JTA > -------------------------------------------------------------- > {code} > --------------------------------------------- > this may caused by race condition/socket timeout/exceed limits, will need to reproduce and research more; > at the beginning I thought it was caused by DB resource locking failed but after I commented out all DB access, the problem still there > put all my code to https://github.com/JonkeyGuan/txbridgeInTomcat8 for reproducing and reference -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 07:54:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 5 Sep 2016 07:54:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2122) Go through JTS code and compare/contrast with capabilities missing in other dist tx code we've got In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13288617#comment-13288617 ] Tom Jenkinson commented on JBTM-2122: ------------------------------------- Observation: when a transaction that is using JTS with JCA in-flow crashes after writing the prepare message, a subsequent XATerminator::commit() message is not sufficient to flush the xa_commit to enlisted XAR. This is different from JTA because we can't know if the TX is making slow progress or it's a genuine recovery scenario. For these types of application the follow is expected: XATerminator::prepare(xid1) CRASH xid1 = XATerminator::recover() XATerminator::commit(xid1) Then, in the JVM where the resource lives: periodicRecoveryScan() // Wait for orphan detection interval periodicRecoveryScan() The second periodicRecoveryScan will effect bottom-up recovery on the XAR and it will try to contact the potentially remote coordinator to ask the state of the transaction (which will be of state committing) > Go through JTS code and compare/contrast with capabilities missing in other dist tx code we've got > -------------------------------------------------------------------------------------------------- > > Key: JBTM-2122 > URL: https://issues.jboss.org/browse/JBTM-2122 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.0.1 > Reporter: Mark Little > Assignee: Michael Musgrove > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 09:00:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 5 Sep 2016 09:00:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2748) Prevent JTS bottom-up recovery from rolling back prepared inflowed JCA transactions In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2748: ----------------------------------- Summary: Prevent JTS bottom-up recovery from rolling back prepared inflowed JCA transactions Key: JBTM-2748 URL: https://issues.jboss.org/browse/JBTM-2748 Project: JBoss Transaction Manager Issue Type: Bug Components: JCA, JTS, Recovery Reporter: Tom Jenkinson Assignee: Tom Jenkinson Priority: Blocker Fix For: 5.next There exists a defect that if a recovering JVM does the following steps: doRecoveryScan() waitForOrphanInterval() doRecoveryScan() *Before* XATerminator::recover is called in the root coordinator then bottom-up recovery will be told there is NoTransaction which is infers as a rollback. I saw two options, one was to have TransactionCacheItem try to peek in the objectstore for ServerTransaction/JCA classes. The alternative is to add a new recovery module that can load the ServerTransaction/JCA classes periodically so the transaction won't be lost. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 09:01:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 5 Sep 2016 09:01:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2748) Prevent JTS bottom-up recovery from rolling back prepared inflowed JCA transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #1066 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Prevent JTS bottom-up recovery from rolling back prepared inflowed JCA transactions > ----------------------------------------------------------------------------------- > > Key: JBTM-2748 > URL: https://issues.jboss.org/browse/JBTM-2748 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA, JTS, Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.next > > > There exists a defect that if a recovering JVM does the following steps: > doRecoveryScan() > waitForOrphanInterval() > doRecoveryScan() > *Before* XATerminator::recover is called in the root coordinator then bottom-up recovery will be told there is NoTransaction which is infers as a rollback. > I saw two options, one was to have TransactionCacheItem try to peek in the objectstore for ServerTransaction/JCA classes. The alternative is to add a new recovery module that can load the ServerTransaction/JCA classes periodically so the transaction won't be lost. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 10:11:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 5 Sep 2016 10:11:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2749: -------------------------------------- Summary: Add an SPI method to lookup imported transactions by Xid Key: JBTM-2749 URL: https://issues.jboss.org/browse/JBTM-2749 Project: JBoss Transaction Manager Issue Type: Feature Request Components: JCA, SPI Affects Versions: 5.3.4.Final Reporter: Michael Musgrove Assignee: Michael Musgrove When EJB remoting sees an incomming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 5 11:32:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 5 Sep 2016 11:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2750) Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2750: ------------------------------------- Summary: Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system Key: JBTM-2750 URL: https://issues.jboss.org/browse/JBTM-2750 Project: JBoss Transaction Manager Issue Type: Enhancement Components: Transaction Core Affects Versions: 4.17.33 Environment: JBoss EA P6.4.8 Reporter: Ondra Chaloupka Assignee: Michael Musgrove Priority: Minor Fix For: 5.next The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default). The following signature can be observed in the log file: {noformat} 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3 {noformat} It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 6 04:36:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 6 Sep 2016 04:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2751) Prevent JTS bottom-up recovery from rolling back prepared inflowed JCA transactions In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2751: ------------------------------------- Summary: Prevent JTS bottom-up recovery from rolling back prepared inflowed JCA transactions Key: JBTM-2751 URL: https://issues.jboss.org/browse/JBTM-2751 Project: JBoss Transaction Manager Issue Type: Bug Components: JCA, JTS, Recovery Reporter: Ondra Chaloupka Assignee: Tom Jenkinson Priority: Blocker Fix For: 5.next There exists a defect that if a recovering JVM does the following steps: doRecoveryScan() waitForOrphanInterval() doRecoveryScan() *Before* XATerminator::recover is called in the root coordinator then bottom-up recovery will be told there is NoTransaction which is infers as a rollback. I saw two options, one was to have TransactionCacheItem try to peek in the objectstore for ServerTransaction/JCA classes. The alternative is to add a new recovery module that can load the ServerTransaction/JCA classes periodically so the transaction won't be lost. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 6 05:43:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 6 Sep 2016 05:43:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2719) tpcall get three seconds delay in the fooapp quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2719: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > tpcall get three seconds delay in the fooapp quickstart > ------------------------------------------------------- > > Key: JBTM-2719 > URL: https://issues.jboss.org/browse/JBTM-2719 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > The apr_pollset_poll in HybridSocketEndpointQueue.cxx Line 392 is blocking and timing out after 3 second. It is the root cause for the tpcall delaying. > So it should try to wake up the polling in non-conversation session while disconnect -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 6 06:50:01 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 6 Sep 2016 06:50:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #13 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > When EJB remoting sees an incomming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 6 09:14:01 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 6 Sep 2016 09:14:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2749: ----------------------------------- Priority: Critical (was: Major) > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > > When EJB remoting sees an incomming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 6 09:14:01 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 6 Sep 2016 09:14:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2749: ----------------------------------- Issue Type: Enhancement (was: Feature Request) > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > > When EJB remoting sees an incomming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 6 14:35:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 6 Sep 2016 14:35:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2747) Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1067 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions > --------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2747 > URL: https://issues.jboss.org/browse/JBTM-2747 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Fix For: 5.next > > > The previous example relied upon the "transport" piece maintaining a list of root transactions it had seen. It is actually possible to use the existing list from the TransactionImple -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 6 15:18:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 6 Sep 2016 15:18:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2748) Prevent JTS bottom-up recovery from rolling back prepared inflowed JCA transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2748: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Prevent JTS bottom-up recovery from rolling back prepared inflowed JCA transactions > ----------------------------------------------------------------------------------- > > Key: JBTM-2748 > URL: https://issues.jboss.org/browse/JBTM-2748 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA, JTS, Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.next > > > There exists a defect that if a recovering JVM does the following steps: > doRecoveryScan() > waitForOrphanInterval() > doRecoveryScan() > *Before* XATerminator::recover is called in the root coordinator then bottom-up recovery will be told there is NoTransaction which is infers as a rollback. > I saw two options, one was to have TransactionCacheItem try to peek in the objectstore for ServerTransaction/JCA classes. The alternative is to add a new recovery module that can load the ServerTransaction/JCA classes periodically so the transaction won't be lost. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 06:58:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 7 Sep 2016 06:58:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289809#comment-13289809 ] Michael Musgrove commented on JBTM-2749: ---------------------------------------- The new SPI method is org.jboss.tm.ExtendedJBossXATerminator and is implemented by our JTA and JTA variants (com.arjuna.ats.internal.jbossatx.jta.jca.XATerminator and com.arjuna.ats.internal.jbossatx.jts.jca.XATerminator) > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > > When EJB remoting sees an incomming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 7 07:00:02 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 7 Sep 2016 07:00:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13289809#comment-13289809 ] Michael Musgrove edited comment on JBTM-2749 at 9/7/16 6:59 AM: ---------------------------------------------------------------- The new SPI method is org.jboss.tm.ExtendedJBossXATerminator and is implemented by both of our JTA and JTS variants (com.arjuna.ats.internal.jbossatx.jta.jca.XATerminator and com.arjuna.ats.internal.jbossatx.jts.jca.XATerminator) was (Author: mmusgrov): The new SPI method is org.jboss.tm.ExtendedJBossXATerminator and is implemented by our JTA and JTA variants (com.arjuna.ats.internal.jbossatx.jta.jca.XATerminator and com.arjuna.ats.internal.jbossatx.jts.jca.XATerminator) > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > > When EJB remoting sees an incomming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 07:48:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 8 Sep 2016 07:48:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2749: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done The new SPI is available in org.jboss:jboss-transaction-spi:7.3.4.Final and the implementation of the SPI is on narayana master > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > When EJB remoting sees an incomming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 8 17:12:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 8 Sep 2016 17:12:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2704) Compensations framework cannot instantiate bean from ear archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2704: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Compensations framework cannot instantiate bean from ear archive > ---------------------------------------------------------------- > > Key: JBTM-2704 > URL: https://issues.jboss.org/browse/JBTM-2704 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed. > Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager. > It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 06:52:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 9 Sep 2016 06:52:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2733) Adding section about inflow transactions and EIS interaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291095#comment-13291095 ] Ondra Chaloupka commented on JBTM-2733: --------------------------------------- Hi [~tomjenkinson], I was wondering on your comment https://issues.jboss.org/browse/JBTM-2733?focusedCommentId=13284121#comment-13284121 and now I found some time to go through the XA spec for it. I wasn't able to find reason behind why the recover sequence should be {{xa_recover(START), xa_commit/rb, xa_recover(END)}} and can't be e.g. like {{xa_recover(START|END), xa_commit/rb}}. Would you be so kind and elaborate a bit on this? Or can you point me to spec/article where I got information how this is expected to be used? It's quite possible that I just haven't read/searched properly. I'm just curious. Thanks in advance. > Adding section about inflow transactions and EIS interaction > ------------------------------------------------------------ > > Key: JBTM-2733 > URL: https://issues.jboss.org/browse/JBTM-2733 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Documentation > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > > I would like ask for enhancing Narayana documentation for section where information about inflow transactions and interaction with EIS would be part of. > This ask for the addition came from discussion about behaviour of inflow transaction on jbossts mailing list. Particularly information how EIS and TM is expected to interoperate during recovery process. E.g. how EIS is expected to finish transaction when TM jvm crash occurs or how EIS is expected to finish transaction when participant of txn involved under management of TM (TM is manager of subordinate transaction) and such participant independently decides to rollback (after prepare is confirmed) which causes heuristic exception being thrown to EIS RAR and transaction is put to heuristic state. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 08:28:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 9 Sep 2016 08:28:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2733) Adding section about inflow transactions and EIS interaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291144#comment-13291144 ] Tom Jenkinson commented on JBTM-2733: ------------------------------------- Sorry, you are right that you can OR them. > Adding section about inflow transactions and EIS interaction > ------------------------------------------------------------ > > Key: JBTM-2733 > URL: https://issues.jboss.org/browse/JBTM-2733 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Documentation > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > > I would like ask for enhancing Narayana documentation for section where information about inflow transactions and interaction with EIS would be part of. > This ask for the addition came from discussion about behaviour of inflow transaction on jbossts mailing list. Particularly information how EIS and TM is expected to interoperate during recovery process. E.g. how EIS is expected to finish transaction when TM jvm crash occurs or how EIS is expected to finish transaction when participant of txn involved under management of TM (TM is manager of subordinate transaction) and such participant independently decides to rollback (after prepare is confirmed) which causes heuristic exception being thrown to EIS RAR and transaction is put to heuristic state. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 9 08:50:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 9 Sep 2016 08:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2733) Adding section about inflow transactions and EIS interaction In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291167#comment-13291167 ] Ondra Chaloupka commented on JBTM-2733: --------------------------------------- Ok, I see. Thank you for confirmation! > Adding section about inflow transactions and EIS interaction > ------------------------------------------------------------ > > Key: JBTM-2733 > URL: https://issues.jboss.org/browse/JBTM-2733 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Documentation > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > > I would like ask for enhancing Narayana documentation for section where information about inflow transactions and interaction with EIS would be part of. > This ask for the addition came from discussion about behaviour of inflow transaction on jbossts mailing list. Particularly information how EIS and TM is expected to interoperate during recovery process. E.g. how EIS is expected to finish transaction when TM jvm crash occurs or how EIS is expected to finish transaction when participant of txn involved under management of TM (TM is manager of subordinate transaction) and such participant independently decides to rollback (after prepare is confirmed) which causes heuristic exception being thrown to EIS RAR and transaction is put to heuristic state. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 13 05:07:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 13 Sep 2016 05:07:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2752) Database connection on POSTGRE required max_prepared_statement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson moved WFLY-7099 to JBTM-2752: ------------------------------------------- Project: JBoss Transaction Manager (was: WildFly) Key: JBTM-2752 (was: WFLY-7099) Component/s: JTA (was: Transactions) Affects Version/s: (was: 8.2.0.Final) > Database connection on POSTGRE required max_prepared_statement > -------------------------------------------------------------- > > Key: JBTM-2752 > URL: https://issues.jboss.org/browse/JBTM-2752 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > > max_prepared_statement is required on the file (postgre.conf) to connect on pgsql base. > If this option wasn't activate, the method end is called twice on PGXAConnection > Please find below original discussion : > https://developer.jboss.org/message/958507#958507 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 13 05:07:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 13 Sep 2016 05:07:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2752) Database connection on POSTGRE required max_prepared_statement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2752: -------------------------------- Fix Version/s: 5.next > Database connection on POSTGRE required max_prepared_statement > -------------------------------------------------------------- > > Key: JBTM-2752 > URL: https://issues.jboss.org/browse/JBTM-2752 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > max_prepared_statement is required on the file (postgre.conf) to connect on pgsql base. > If this option wasn't activate, the method end is called twice on PGXAConnection > Please find below original discussion : > https://developer.jboss.org/message/958507#958507 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 13 05:08:06 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 13 Sep 2016 05:08:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2752) Database connection on POSTGRE required max_prepared_statement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2752: -------------------------------- Forum Reference: https://developer.jboss.org/message/958553?et=watches.email.thread#958553 > Database connection on POSTGRE required max_prepared_statement > -------------------------------------------------------------- > > Key: JBTM-2752 > URL: https://issues.jboss.org/browse/JBTM-2752 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > max_prepared_statement is required on the file (postgre.conf) to connect on pgsql base. > If this option wasn't activate, the method end is called twice on PGXAConnection > Please find below original discussion : > https://developer.jboss.org/message/958507#958507 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 13 05:09:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 13 Sep 2016 05:09:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2752) Database connection on POSTGRE required max_prepared_statement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2752: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1025 > Database connection on POSTGRE required max_prepared_statement > -------------------------------------------------------------- > > Key: JBTM-2752 > URL: https://issues.jboss.org/browse/JBTM-2752 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > max_prepared_statement is required on the file (postgre.conf) to connect on pgsql base. > If this option wasn't activate, the method end is called twice on PGXAConnection > Please find below original discussion : > https://developer.jboss.org/message/958507#958507 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 13 05:30:00 2016 From: issues at jboss.org (=?UTF-8?Q?Florian_M=C3=A9lot_=28JIRA=29?=) Date: Tue, 13 Sep 2016 05:30:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2753) Method end on PGXAConnection has been called twice In-Reply-To: References: Message-ID: Florian M?lot created JBTM-2753: ----------------------------------- Summary: Method end on PGXAConnection has been called twice Key: JBTM-2753 URL: https://issues.jboss.org/browse/JBTM-2753 Project: JBoss Transaction Manager Issue Type: Bug Components: JTS Affects Versions: 5.3.0.Final Environment: Wildfly 8 Reporter: Florian M?lot Priority: Minor Fix For: 5.later End method from PGXAConnection has been called twice when an EJB called another EJB to get data from psql database (9.2.5) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 13 05:35:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 13 Sep 2016 05:35:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2753) Method end on PGXAConnection has been called twice In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2753: -------------------------------- Fix Version/s: 5.next (was: 5.later) > Method end on PGXAConnection has been called twice > -------------------------------------------------- > > Key: JBTM-2753 > URL: https://issues.jboss.org/browse/JBTM-2753 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.0.Final > Environment: Wildfly 8 > Reporter: Florian M?lot > Priority: Minor > Fix For: 5.next > > > End method from PGXAConnection has been called twice when an EJB called another EJB to get data from psql database (9.2.5) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 13 05:35:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 13 Sep 2016 05:35:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2753) Method end on PGXAConnection has been called twice In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2753: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1025 > Method end on PGXAConnection has been called twice > -------------------------------------------------- > > Key: JBTM-2753 > URL: https://issues.jboss.org/browse/JBTM-2753 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.0.Final > Environment: Wildfly 8 > Reporter: Florian M?lot > Priority: Minor > Fix For: 5.next > > > End method from PGXAConnection has been called twice when an EJB called another EJB to get data from psql database (9.2.5) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 13 08:17:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 13 Sep 2016 08:17:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2754) Class not found in JCA Tomcat quickstart In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2754: ------------------------------------- Summary: Class not found in JCA Tomcat quickstart Key: JBTM-2754 URL: https://issues.jboss.org/browse/JBTM-2754 Project: JBoss Transaction Manager Issue Type: Bug Components: Demonstrator Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Minor Fix For: 5.next {code} ------------------------------------------------------------------------------- Test set: org.jboss.narayana.quickstart.jca.model.CustomerDAOTest ------------------------------------------------------------------------------- Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 1.125 sec <<< FAILURE! org.jboss.narayana.quickstart.jca.model.CustomerDAOTest Time elapsed: 0 sec <<< ERROR! com.github.fungal.spi.deployers.DeployException: Deployment file:/C:/hudson/workspace/narayana-quickstarts-catelyn/jca-and-tomcat/target/classes/transaction.xml failed at com.github.fungal.impl.DeploymentDeployer.deploy(DeploymentDeployer.java:157) at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:144) at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:82) at org.jboss.jca.embedded.EmbeddedJCA.deploy(EmbeddedJCA.java:313) at org.jboss.jca.embedded.EmbeddedJCA.startup(EmbeddedJCA.java:122) at org.jboss.narayana.quickstart.jca.common.AbstractTest.beforeClass(AbstractTest.java:52) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) at com.sun.proxy.$Proxy0.invoke(Unknown Source) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) Caused by: com.github.fungal.spi.deployers.DeployException: Installing bean XATerminator at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:200) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NoClassDefFoundError: org/jboss/tm/ExtendedJBossXATerminator at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:760) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) at java.net.URLClassLoader.access$100(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:368) at java.net.URLClassLoader$1.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:361) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at com.github.fungal.impl.classloader.ParentFirstClassLoader.loadClass(ParentFirstClassLoader.java:67) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348) at com.github.fungal.impl.BeanDeployer.createBean(BeanDeployer.java:318) at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:186) ... 5 more Caused by: java.lang.ClassNotFoundException: org.jboss.tm.ExtendedJBossXATerminator at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 22 more org.jboss.narayana.quickstart.jca.model.CustomerDAOTest Time elapsed: 0 sec <<< ERROR! java.lang.IllegalStateException: Container not started at org.jboss.jca.embedded.EmbeddedJCA.undeploy(EmbeddedJCA.java:327) at org.jboss.narayana.quickstart.jca.common.AbstractTest.afterClass(AbstractTest.java:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) at com.sun.proxy.$Proxy0.invoke(Unknown Source) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) {code} {code} ------------------------------------------------------------------------------- Test set: org.jboss.narayana.quickstart.jca.xa.XAResourcesTest ------------------------------------------------------------------------------- Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.047 sec <<< FAILURE! org.jboss.narayana.quickstart.jca.xa.XAResourcesTest Time elapsed: 0.079 sec <<< ERROR! com.github.fungal.spi.deployers.DeployException: Deployment file:/C:/hudson/workspace/narayana-quickstarts-catelyn/jca-and-tomcat/target/classes/transaction.xml failed at com.github.fungal.impl.DeploymentDeployer.deploy(DeploymentDeployer.java:157) at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:144) at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:82) at org.jboss.jca.embedded.EmbeddedJCA.deploy(EmbeddedJCA.java:313) at org.jboss.jca.embedded.EmbeddedJCA.startup(EmbeddedJCA.java:122) at org.jboss.narayana.quickstart.jca.common.AbstractTest.beforeClass(AbstractTest.java:52) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) at com.sun.proxy.$Proxy0.invoke(Unknown Source) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) Caused by: com.github.fungal.spi.deployers.DeployException: Installing bean XATerminator at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:200) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.NoClassDefFoundError: org/jboss/tm/ExtendedJBossXATerminator at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:760) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) at java.net.URLClassLoader.access$100(URLClassLoader.java:73) at java.net.URLClassLoader$1.run(URLClassLoader.java:368) at java.net.URLClassLoader$1.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:361) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at com.github.fungal.impl.classloader.ParentFirstClassLoader.loadClass(ParentFirstClassLoader.java:67) at com.github.fungal.impl.classloader.ParentFirstClassLoader.loadClass(ParentFirstClassLoader.java:67) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:348) at com.github.fungal.impl.BeanDeployer.createBean(BeanDeployer.java:318) at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:186) ... 5 more Caused by: java.lang.ClassNotFoundException: org.jboss.tm.ExtendedJBossXATerminator at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 23 more org.jboss.narayana.quickstart.jca.xa.XAResourcesTest Time elapsed: 0.079 sec <<< ERROR! java.lang.IllegalStateException: Container not started at org.jboss.jca.embedded.EmbeddedJCA.undeploy(EmbeddedJCA.java:327) at org.jboss.narayana.quickstart.jca.common.AbstractTest.afterClass(AbstractTest.java:59) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) at com.sun.proxy.$Proxy0.invoke(Unknown Source) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 13 08:45:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 13 Sep 2016 08:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2683) The txfooapp quickstart segment fault In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2683: ---------------------------- Description: This fault happens when destroying the XAResourceManager, {code} int rv = xa_switch_->xa_close_entry((char *) closeString_, rmid_, TMNOFLAGS); {code} it looks like that this function in the oracle client library is failed. but unfortunately we can not archive the core dump file > The txfooapp quickstart segment fault > ------------------------------------- > > Key: JBTM-2683 > URL: https://issues.jboss.org/browse/JBTM-2683 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > > This fault happens when destroying the XAResourceManager, > {code} > int rv = xa_switch_->xa_close_entry((char *) closeString_, rmid_, TMNOFLAGS); > {code} > it looks like that this function in the oracle client library is failed. but unfortunately we can not archive the core dump file -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 13 08:48:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 13 Sep 2016 08:48:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2683) The txfooapp quickstart segment fault In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng resolved JBTM-2683. ----------------------------- Resolution: Cannot Reproduce Bug I just added the "**/core.*" in the archive files in the narayana-quickstarts configuration. If it happens again, it could be useful to detect the error with the core dump file. > The txfooapp quickstart segment fault > ------------------------------------- > > Key: JBTM-2683 > URL: https://issues.jboss.org/browse/JBTM-2683 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > > This fault happens when destroying the XAResourceManager, > {code} > int rv = xa_switch_->xa_close_entry((char *) closeString_, rmid_, TMNOFLAGS); > {code} > it looks like that this function in the oracle client library is failed. but unfortunately we can not archive the core dump file -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 13 09:08:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 13 Sep 2016 09:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2754) Class not found in JCA Tomcat quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris reassigned JBTM-2754: ------------------------------------- Assignee: Michael Musgrove (was: Gytis Trikleris) > Class not found in JCA Tomcat quickstart > ---------------------------------------- > > Key: JBTM-2754 > URL: https://issues.jboss.org/browse/JBTM-2754 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > {code} > ------------------------------------------------------------------------------- > Test set: org.jboss.narayana.quickstart.jca.model.CustomerDAOTest > ------------------------------------------------------------------------------- > Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 1.125 sec <<< FAILURE! > org.jboss.narayana.quickstart.jca.model.CustomerDAOTest Time elapsed: 0 sec <<< ERROR! > com.github.fungal.spi.deployers.DeployException: Deployment file:/C:/hudson/workspace/narayana-quickstarts-catelyn/jca-and-tomcat/target/classes/transaction.xml failed > at com.github.fungal.impl.DeploymentDeployer.deploy(DeploymentDeployer.java:157) > at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:144) > at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:82) > at org.jboss.jca.embedded.EmbeddedJCA.deploy(EmbeddedJCA.java:313) > at org.jboss.jca.embedded.EmbeddedJCA.startup(EmbeddedJCA.java:122) > at org.jboss.narayana.quickstart.jca.common.AbstractTest.beforeClass(AbstractTest.java:52) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > Caused by: com.github.fungal.spi.deployers.DeployException: Installing bean XATerminator > at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:200) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NoClassDefFoundError: org/jboss/tm/ExtendedJBossXATerminator > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:760) > at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) > at java.net.URLClassLoader.access$100(URLClassLoader.java:73) > at java.net.URLClassLoader$1.run(URLClassLoader.java:368) > at java.net.URLClassLoader$1.run(URLClassLoader.java:362) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:361) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at com.github.fungal.impl.classloader.ParentFirstClassLoader.loadClass(ParentFirstClassLoader.java:67) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:348) > at com.github.fungal.impl.BeanDeployer.createBean(BeanDeployer.java:318) > at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:186) > ... 5 more > Caused by: java.lang.ClassNotFoundException: org.jboss.tm.ExtendedJBossXATerminator > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 22 more > org.jboss.narayana.quickstart.jca.model.CustomerDAOTest Time elapsed: 0 sec <<< ERROR! > java.lang.IllegalStateException: Container not started > at org.jboss.jca.embedded.EmbeddedJCA.undeploy(EmbeddedJCA.java:327) > at org.jboss.narayana.quickstart.jca.common.AbstractTest.afterClass(AbstractTest.java:59) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > {code} > {code} > ------------------------------------------------------------------------------- > Test set: org.jboss.narayana.quickstart.jca.xa.XAResourcesTest > ------------------------------------------------------------------------------- > Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.047 sec <<< FAILURE! > org.jboss.narayana.quickstart.jca.xa.XAResourcesTest Time elapsed: 0.079 sec <<< ERROR! > com.github.fungal.spi.deployers.DeployException: Deployment file:/C:/hudson/workspace/narayana-quickstarts-catelyn/jca-and-tomcat/target/classes/transaction.xml failed > at com.github.fungal.impl.DeploymentDeployer.deploy(DeploymentDeployer.java:157) > at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:144) > at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:82) > at org.jboss.jca.embedded.EmbeddedJCA.deploy(EmbeddedJCA.java:313) > at org.jboss.jca.embedded.EmbeddedJCA.startup(EmbeddedJCA.java:122) > at org.jboss.narayana.quickstart.jca.common.AbstractTest.beforeClass(AbstractTest.java:52) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > Caused by: com.github.fungal.spi.deployers.DeployException: Installing bean XATerminator > at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:200) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NoClassDefFoundError: org/jboss/tm/ExtendedJBossXATerminator > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:760) > at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) > at java.net.URLClassLoader.access$100(URLClassLoader.java:73) > at java.net.URLClassLoader$1.run(URLClassLoader.java:368) > at java.net.URLClassLoader$1.run(URLClassLoader.java:362) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:361) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at com.github.fungal.impl.classloader.ParentFirstClassLoader.loadClass(ParentFirstClassLoader.java:67) > at com.github.fungal.impl.classloader.ParentFirstClassLoader.loadClass(ParentFirstClassLoader.java:67) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:348) > at com.github.fungal.impl.BeanDeployer.createBean(BeanDeployer.java:318) > at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:186) > ... 5 more > Caused by: java.lang.ClassNotFoundException: org.jboss.tm.ExtendedJBossXATerminator > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 23 more > org.jboss.narayana.quickstart.jca.xa.XAResourcesTest Time elapsed: 0.079 sec <<< ERROR! > java.lang.IllegalStateException: Container not started > at org.jboss.jca.embedded.EmbeddedJCA.undeploy(EmbeddedJCA.java:327) > at org.jboss.narayana.quickstart.jca.common.AbstractTest.afterClass(AbstractTest.java:59) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 15 07:05:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 15 Sep 2016 07:05:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2755) Allow btadmin to load servers from 127.0.0.1 In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2755: ----------------------------------- Summary: Allow btadmin to load servers from 127.0.0.1 Key: JBTM-2755 URL: https://issues.jboss.org/browse/JBTM-2755 Project: JBoss Transaction Manager Issue Type: Feature Request Components: BlackTie Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next This means that when we add new nodes we don't have to add to the test each time -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 16 04:21:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Sep 2016 04:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2260) BlackTie does not build on CentOS 7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2260: --------------------------------- > BlackTie does not build on CentOS 7 > ----------------------------------- > > Key: JBTM-2260 > URL: https://issues.jboss.org/browse/JBTM-2260 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.0.4 > > > [hudson at sansa ~]$ uname -a > Linux sansa.buildnet.ncl.jboss.com 3.10.0-123.6.3.el7.x86_64 #1 SMP Wed Aug 6 21:12:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > http://172.17.131.2/view/Narayana+BlackTie/job/narayana-jdbcobjectstore/DB_TYPE=mysql,jdk=jdk7.latest,slave=linux/101/console > {quote} > test-compile: > [mkdir] Created dir: /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [copy] Copying 6 files to /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [cc] 11 total files to be compiled. > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?virtual void TestAtmiBrokerXml::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:34:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=."); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:35:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_env()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:41:45: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:42:41: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_define_adminservice()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:155:47: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=wrongtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_same_service()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:167:46: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=sametest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_invalid_xml()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:179:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=invalidtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_no_config()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:191:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=noexisttest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:35:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=linux"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:42:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In function ?void* activateWaiter(apr_thread_t*, void*)?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:31:9: warning: unused variable ?ret? [-Wunused-variable] > [cc] int ret = waiter->svc(); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In member function ?virtual void TestSynchronizableObject::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:76:6: warning: unused variable ?argc? [-Wunused-variable] > [cc] int argc = 0; > [cc] ^ > [cc] Starting link > [cc] /lib64/libaprutil-1.so.0: undefined reference to `apr_pool_pre_cleanup_register' > [cc] collect2: error: ld returned 1 exit status > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 16 04:21:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Sep 2016 04:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2260) BlackTie does not build on CentOS 7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2260: -------------------------------- Status: Pull Request Sent (was: Reopened) Git Pull Request: https://github.com/jbosstm/narayana/pull/749, https://github.com/jbosstm/narayana/pull/1070 (was: https://github.com/jbosstm/narayana/pull/749) > BlackTie does not build on CentOS 7 > ----------------------------------- > > Key: JBTM-2260 > URL: https://issues.jboss.org/browse/JBTM-2260 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.0.4, 5.next > > > [hudson at sansa ~]$ uname -a > Linux sansa.buildnet.ncl.jboss.com 3.10.0-123.6.3.el7.x86_64 #1 SMP Wed Aug 6 21:12:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > http://172.17.131.2/view/Narayana+BlackTie/job/narayana-jdbcobjectstore/DB_TYPE=mysql,jdk=jdk7.latest,slave=linux/101/console > {quote} > test-compile: > [mkdir] Created dir: /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [copy] Copying 6 files to /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [cc] 11 total files to be compiled. > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?virtual void TestAtmiBrokerXml::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:34:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=."); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:35:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_env()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:41:45: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:42:41: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_define_adminservice()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:155:47: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=wrongtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_same_service()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:167:46: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=sametest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_invalid_xml()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:179:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=invalidtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_no_config()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:191:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=noexisttest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:35:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=linux"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:42:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In function ?void* activateWaiter(apr_thread_t*, void*)?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:31:9: warning: unused variable ?ret? [-Wunused-variable] > [cc] int ret = waiter->svc(); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In member function ?virtual void TestSynchronizableObject::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:76:6: warning: unused variable ?argc? [-Wunused-variable] > [cc] int argc = 0; > [cc] ^ > [cc] Starting link > [cc] /lib64/libaprutil-1.so.0: undefined reference to `apr_pool_pre_cleanup_register' > [cc] collect2: error: ld returned 1 exit status > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 16 04:21:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Sep 2016 04:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2260) BlackTie does not build on CentOS 7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2260: -------------------------------- Fix Version/s: 5.next > BlackTie does not build on CentOS 7 > ----------------------------------- > > Key: JBTM-2260 > URL: https://issues.jboss.org/browse/JBTM-2260 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.0.4, 5.next > > > [hudson at sansa ~]$ uname -a > Linux sansa.buildnet.ncl.jboss.com 3.10.0-123.6.3.el7.x86_64 #1 SMP Wed Aug 6 21:12:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > http://172.17.131.2/view/Narayana+BlackTie/job/narayana-jdbcobjectstore/DB_TYPE=mysql,jdk=jdk7.latest,slave=linux/101/console > {quote} > test-compile: > [mkdir] Created dir: /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [copy] Copying 6 files to /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [cc] 11 total files to be compiled. > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?virtual void TestAtmiBrokerXml::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:34:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=."); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:35:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_env()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:41:45: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:42:41: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_define_adminservice()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:155:47: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=wrongtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_same_service()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:167:46: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=sametest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_invalid_xml()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:179:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=invalidtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_no_config()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:191:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=noexisttest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:35:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=linux"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:42:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In function ?void* activateWaiter(apr_thread_t*, void*)?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:31:9: warning: unused variable ?ret? [-Wunused-variable] > [cc] int ret = waiter->svc(); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In member function ?virtual void TestSynchronizableObject::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:76:6: warning: unused variable ?argc? [-Wunused-variable] > [cc] int argc = 0; > [cc] ^ > [cc] Starting link > [cc] /lib64/libaprutil-1.so.0: undefined reference to `apr_pool_pre_cleanup_register' > [cc] collect2: error: ld returned 1 exit status > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 16 04:22:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 16 Sep 2016 04:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2260) BlackTie does not build on CentOS 7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2260: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Rejected This looks like it was a conflict with the old version of APR which seems resolved now > BlackTie does not build on CentOS 7 > ----------------------------------- > > Key: JBTM-2260 > URL: https://issues.jboss.org/browse/JBTM-2260 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next, 5.0.4 > > > [hudson at sansa ~]$ uname -a > Linux sansa.buildnet.ncl.jboss.com 3.10.0-123.6.3.el7.x86_64 #1 SMP Wed Aug 6 21:12:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > http://172.17.131.2/view/Narayana+BlackTie/job/narayana-jdbcobjectstore/DB_TYPE=mysql,jdk=jdk7.latest,slave=linux/101/console > {quote} > test-compile: > [mkdir] Created dir: /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [copy] Copying 6 files to /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [cc] 11 total files to be compiled. > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?virtual void TestAtmiBrokerXml::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:34:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=."); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:35:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_env()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:41:45: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:42:41: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_define_adminservice()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:155:47: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=wrongtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_same_service()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:167:46: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=sametest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_invalid_xml()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:179:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=invalidtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_no_config()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:191:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=noexisttest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:35:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=linux"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:42:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In function ?void* activateWaiter(apr_thread_t*, void*)?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:31:9: warning: unused variable ?ret? [-Wunused-variable] > [cc] int ret = waiter->svc(); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In member function ?virtual void TestSynchronizableObject::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:76:6: warning: unused variable ?argc? [-Wunused-variable] > [cc] int argc = 0; > [cc] ^ > [cc] Starting link > [cc] /lib64/libaprutil-1.so.0: undefined reference to `apr_pool_pre_cleanup_register' > [cc] collect2: error: ld returned 1 exit status > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 16 14:41:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 16 Sep 2016 14:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2110) Investigate support for IBM ORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #754 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Investigate support for IBM ORB > ------------------------------- > > Key: JBTM-2110 > URL: https://issues.jboss.org/browse/JBTM-2110 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.later > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Mon Sep 19 04:46:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 19 Sep 2016 04:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2754) Class not found in JCA Tomcat quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2754. --------------------------------- Resolution: Done Upgrade SPI in WildFly to 7.3.4.Final > Class not found in JCA Tomcat quickstart > ---------------------------------------- > > Key: JBTM-2754 > URL: https://issues.jboss.org/browse/JBTM-2754 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > {code} > ------------------------------------------------------------------------------- > Test set: org.jboss.narayana.quickstart.jca.model.CustomerDAOTest > ------------------------------------------------------------------------------- > Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 1.125 sec <<< FAILURE! > org.jboss.narayana.quickstart.jca.model.CustomerDAOTest Time elapsed: 0 sec <<< ERROR! > com.github.fungal.spi.deployers.DeployException: Deployment file:/C:/hudson/workspace/narayana-quickstarts-catelyn/jca-and-tomcat/target/classes/transaction.xml failed > at com.github.fungal.impl.DeploymentDeployer.deploy(DeploymentDeployer.java:157) > at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:144) > at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:82) > at org.jboss.jca.embedded.EmbeddedJCA.deploy(EmbeddedJCA.java:313) > at org.jboss.jca.embedded.EmbeddedJCA.startup(EmbeddedJCA.java:122) > at org.jboss.narayana.quickstart.jca.common.AbstractTest.beforeClass(AbstractTest.java:52) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > Caused by: com.github.fungal.spi.deployers.DeployException: Installing bean XATerminator > at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:200) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NoClassDefFoundError: org/jboss/tm/ExtendedJBossXATerminator > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:760) > at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) > at java.net.URLClassLoader.access$100(URLClassLoader.java:73) > at java.net.URLClassLoader$1.run(URLClassLoader.java:368) > at java.net.URLClassLoader$1.run(URLClassLoader.java:362) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:361) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at com.github.fungal.impl.classloader.ParentFirstClassLoader.loadClass(ParentFirstClassLoader.java:67) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:348) > at com.github.fungal.impl.BeanDeployer.createBean(BeanDeployer.java:318) > at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:186) > ... 5 more > Caused by: java.lang.ClassNotFoundException: org.jboss.tm.ExtendedJBossXATerminator > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 22 more > org.jboss.narayana.quickstart.jca.model.CustomerDAOTest Time elapsed: 0 sec <<< ERROR! > java.lang.IllegalStateException: Container not started > at org.jboss.jca.embedded.EmbeddedJCA.undeploy(EmbeddedJCA.java:327) > at org.jboss.narayana.quickstart.jca.common.AbstractTest.afterClass(AbstractTest.java:59) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > {code} > {code} > ------------------------------------------------------------------------------- > Test set: org.jboss.narayana.quickstart.jca.xa.XAResourcesTest > ------------------------------------------------------------------------------- > Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.047 sec <<< FAILURE! > org.jboss.narayana.quickstart.jca.xa.XAResourcesTest Time elapsed: 0.079 sec <<< ERROR! > com.github.fungal.spi.deployers.DeployException: Deployment file:/C:/hudson/workspace/narayana-quickstarts-catelyn/jca-and-tomcat/target/classes/transaction.xml failed > at com.github.fungal.impl.DeploymentDeployer.deploy(DeploymentDeployer.java:157) > at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:144) > at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:82) > at org.jboss.jca.embedded.EmbeddedJCA.deploy(EmbeddedJCA.java:313) > at org.jboss.jca.embedded.EmbeddedJCA.startup(EmbeddedJCA.java:122) > at org.jboss.narayana.quickstart.jca.common.AbstractTest.beforeClass(AbstractTest.java:52) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > Caused by: com.github.fungal.spi.deployers.DeployException: Installing bean XATerminator > at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:200) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NoClassDefFoundError: org/jboss/tm/ExtendedJBossXATerminator > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:760) > at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) > at java.net.URLClassLoader.access$100(URLClassLoader.java:73) > at java.net.URLClassLoader$1.run(URLClassLoader.java:368) > at java.net.URLClassLoader$1.run(URLClassLoader.java:362) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:361) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at com.github.fungal.impl.classloader.ParentFirstClassLoader.loadClass(ParentFirstClassLoader.java:67) > at com.github.fungal.impl.classloader.ParentFirstClassLoader.loadClass(ParentFirstClassLoader.java:67) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:348) > at com.github.fungal.impl.BeanDeployer.createBean(BeanDeployer.java:318) > at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:186) > ... 5 more > Caused by: java.lang.ClassNotFoundException: org.jboss.tm.ExtendedJBossXATerminator > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 23 more > org.jboss.narayana.quickstart.jca.xa.XAResourcesTest Time elapsed: 0.079 sec <<< ERROR! > java.lang.IllegalStateException: Container not started > at org.jboss.jca.embedded.EmbeddedJCA.undeploy(EmbeddedJCA.java:327) > at org.jboss.narayana.quickstart.jca.common.AbstractTest.afterClass(AbstractTest.java:59) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 20 03:57:00 2016 From: issues at jboss.org (davidkarlsen (JIRA)) Date: Tue, 20 Sep 2016 03:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2676) Allow TransactionalDriver connection.close() in afterCompletion In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295457#comment-13295457 ] davidkarlsen commented on JBTM-2676: ------------------------------------ Any movement on this? Are there any workarounds? We're currently struggling with this with spring 4.3.3 (e.g. standalone JTA) + Hibernate 5.1.x (and also in hibernate 5.2.x) and narayana 5.3.4 > Allow TransactionalDriver connection.close() in afterCompletion > --------------------------------------------------------------- > > Key: JBTM-2676 > URL: https://issues.jboss.org/browse/JBTM-2676 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Hibernate closes connections in afterCompletion. However, TransactionalDriver requires transaction to be in an active state in order to delist resource. > See new JTA and Hibernate standalone quickstart for reproduction. > {code} > 2016-06-15 02:21:07,413 [main] WARN com.arjuna.ats.jta - ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization at e4b6f47 with exception > org.hibernate.exception.GenericJDBCException: Unable to release JDBC Connection > at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:111) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:97) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:172) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:135) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:290) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransactionCompletion(JdbcCoordinatorImpl.java:490) > at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.afterCompletion(JtaTransactionCoordinatorImpl.java:345) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.doAfterCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:60) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl.afterCompletion(SynchronizationCallbackCoordinatorTrackingImpl.java:72) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.afterCompletion(RegisteredSynchronization.java:44) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:473) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:127) > at com.arjuna.ats.arjuna.AtomicAction.abort(AtomicAction.java:186) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1282) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143) > at org.jboss.narayana.quickstart.jta.TestCase.testRollback(TestCase.java:145) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > Caused by: java.sql.SQLException: ARJUNA017020: Transaction is not active on the thread! > at com.arjuna.ats.internal.jdbc.ConnectionImple.checkTransaction(ConnectionImple.java:1071) > at com.arjuna.ats.internal.jdbc.ConnectionImple.isClosed(ConnectionImple.java:417) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:166) > ... 45 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 20 04:33:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Tue, 20 Sep 2016 04:33:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2676) Allow TransactionalDriver connection.close() in afterCompletion In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295466#comment-13295466 ] Gytis Trikleris commented on JBTM-2676: --------------------------------------- [~davidkarlsen], I haven't worked on this yet. But I can take a look this or next week. > Allow TransactionalDriver connection.close() in afterCompletion > --------------------------------------------------------------- > > Key: JBTM-2676 > URL: https://issues.jboss.org/browse/JBTM-2676 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Hibernate closes connections in afterCompletion. However, TransactionalDriver requires transaction to be in an active state in order to delist resource. > See new JTA and Hibernate standalone quickstart for reproduction. > {code} > 2016-06-15 02:21:07,413 [main] WARN com.arjuna.ats.jta - ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization at e4b6f47 with exception > org.hibernate.exception.GenericJDBCException: Unable to release JDBC Connection > at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:111) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:97) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:172) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:135) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:290) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransactionCompletion(JdbcCoordinatorImpl.java:490) > at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.afterCompletion(JtaTransactionCoordinatorImpl.java:345) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.doAfterCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:60) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl.afterCompletion(SynchronizationCallbackCoordinatorTrackingImpl.java:72) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.afterCompletion(RegisteredSynchronization.java:44) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:473) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:127) > at com.arjuna.ats.arjuna.AtomicAction.abort(AtomicAction.java:186) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1282) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143) > at org.jboss.narayana.quickstart.jta.TestCase.testRollback(TestCase.java:145) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > Caused by: java.sql.SQLException: ARJUNA017020: Transaction is not active on the thread! > at com.arjuna.ats.internal.jdbc.ConnectionImple.checkTransaction(ConnectionImple.java:1071) > at com.arjuna.ats.internal.jdbc.ConnectionImple.isClosed(ConnectionImple.java:417) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:166) > ... 45 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 20 05:45:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 20 Sep 2016 05:45:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2676) Allow TransactionalDriver connection.close() in afterCompletion In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2676: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1022 > Allow TransactionalDriver connection.close() in afterCompletion > --------------------------------------------------------------- > > Key: JBTM-2676 > URL: https://issues.jboss.org/browse/JBTM-2676 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Hibernate closes connections in afterCompletion. However, TransactionalDriver requires transaction to be in an active state in order to delist resource. > See new JTA and Hibernate standalone quickstart for reproduction. > {code} > 2016-06-15 02:21:07,413 [main] WARN com.arjuna.ats.jta - ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization at e4b6f47 with exception > org.hibernate.exception.GenericJDBCException: Unable to release JDBC Connection > at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:111) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:97) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:172) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:135) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:290) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransactionCompletion(JdbcCoordinatorImpl.java:490) > at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.afterCompletion(JtaTransactionCoordinatorImpl.java:345) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.doAfterCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:60) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl.afterCompletion(SynchronizationCallbackCoordinatorTrackingImpl.java:72) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.afterCompletion(RegisteredSynchronization.java:44) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:473) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:127) > at com.arjuna.ats.arjuna.AtomicAction.abort(AtomicAction.java:186) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1282) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143) > at org.jboss.narayana.quickstart.jta.TestCase.testRollback(TestCase.java:145) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > Caused by: java.sql.SQLException: ARJUNA017020: Transaction is not active on the thread! > at com.arjuna.ats.internal.jdbc.ConnectionImple.checkTransaction(ConnectionImple.java:1071) > at com.arjuna.ats.internal.jdbc.ConnectionImple.isClosed(ConnectionImple.java:417) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:166) > ... 45 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 20 05:46:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 20 Sep 2016 05:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2676) Allow TransactionalDriver connection.close() in afterCompletion In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295506#comment-13295506 ] Tom Jenkinson commented on JBTM-2676: ------------------------------------- I had a PR for this open a little while but I just tidied it up. It passes the test that Gytis added a while back, I rebased it and am re-running. https://github.com/jbosstm/narayana/pull/1022 > Allow TransactionalDriver connection.close() in afterCompletion > --------------------------------------------------------------- > > Key: JBTM-2676 > URL: https://issues.jboss.org/browse/JBTM-2676 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Hibernate closes connections in afterCompletion. However, TransactionalDriver requires transaction to be in an active state in order to delist resource. > See new JTA and Hibernate standalone quickstart for reproduction. > {code} > 2016-06-15 02:21:07,413 [main] WARN com.arjuna.ats.jta - ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization at e4b6f47 with exception > org.hibernate.exception.GenericJDBCException: Unable to release JDBC Connection > at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:111) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:97) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:172) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:135) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:290) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransactionCompletion(JdbcCoordinatorImpl.java:490) > at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.afterCompletion(JtaTransactionCoordinatorImpl.java:345) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.doAfterCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:60) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl.afterCompletion(SynchronizationCallbackCoordinatorTrackingImpl.java:72) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.afterCompletion(RegisteredSynchronization.java:44) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:473) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:127) > at com.arjuna.ats.arjuna.AtomicAction.abort(AtomicAction.java:186) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1282) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143) > at org.jboss.narayana.quickstart.jta.TestCase.testRollback(TestCase.java:145) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > Caused by: java.sql.SQLException: ARJUNA017020: Transaction is not active on the thread! > at com.arjuna.ats.internal.jdbc.ConnectionImple.checkTransaction(ConnectionImple.java:1071) > at com.arjuna.ats.internal.jdbc.ConnectionImple.isClosed(ConnectionImple.java:417) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:166) > ... 45 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 20 09:22:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 20 Sep 2016 09:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reopened JBTM-2749: ------------------------------------ reopening to add more SPI methods > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > When EJB remoting sees an incomming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 20 09:42:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 20 Sep 2016 09:42:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2756) Static code analysis: nondeterministic locking behavior at ThreadAssociations#removeAll In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2756: ------------------------------------- Summary: Static code analysis: nondeterministic locking behavior at ThreadAssociations#removeAll Key: JBTM-2756 URL: https://issues.jboss.org/browse/JBTM-2756 Project: JBoss Transaction Manager Issue Type: Bug Components: JTS Affects Versions: 5.3.4.Final Reporter: Ondra Chaloupka Static code analysis category: Nondeterministic locking behavior _CID-17602_: Bad choice of lock object - Nondeterministic locking behavior in class `ThreadAssociations` [1] at method `removeAll`. There is used synchronized block where lock is acquired at `globalTxAssociations` and `txAssociations`. The problem (one for txAssociations is described as) lock_acquire: Acquiring lock `com.arjuna.ats.jts.extensions.`ThreadAssociations.txAssociations`. lock_on_assigned_field: Locking on the object referenced by field `ThreadAssociations.txAssociations`. This lock acquisition may race with another thread assigning to this field. The contents of `ThreadAssociations.txAssociations` may change while a thread is inside the critical section, allowing two threads to enter the critical section simultaneously. * Instead of using `ThreadAssociations.txAssociations` as a lock, create a final field of type Object which is only used as a lock. assign_to_field: The expression `ThreadAssociations.txAssociations = null` assigns a new value to `ThreadAssociations.txAssociations`, a field whose contents are used as a lock. The locking behavior of this function may allow this assignment to occur multiple times. Tom's reaction on this {quote} I think that the bug is that there is any synchronization at all on txAssociations because it looks to be indexed by Thread.currentThread(). {quote} [1] https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/jts/extensions/ThreadAssociations.java#L125 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 20 09:43:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 20 Sep 2016 09:43:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2756) Static code analysis: nondeterministic locking behavior at ThreadAssociations#removeAll In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-2756: ------------------------------------- Assignee: Tom Jenkinson > Static code analysis: nondeterministic locking behavior at ThreadAssociations#removeAll > --------------------------------------------------------------------------------------- > > Key: JBTM-2756 > URL: https://issues.jboss.org/browse/JBTM-2756 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > > Static code analysis category: Nondeterministic locking behavior > _CID-17602_: Bad choice of lock object - Nondeterministic locking behavior > in class `ThreadAssociations` [1] at method `removeAll`. There is used synchronized block > where lock is acquired at `globalTxAssociations` and `txAssociations`. > The problem (one for txAssociations is described as) > lock_acquire: Acquiring lock `com.arjuna.ats.jts.extensions.`ThreadAssociations.txAssociations`. > lock_on_assigned_field: Locking on the object referenced by field `ThreadAssociations.txAssociations`. This lock acquisition may race with another thread assigning to this field. The contents of `ThreadAssociations.txAssociations` may change while a thread is inside the critical section, allowing two threads to enter the critical section simultaneously. > * Instead of using `ThreadAssociations.txAssociations` as a lock, create a final field of type Object which is only used as a lock. > assign_to_field: The expression `ThreadAssociations.txAssociations = null` assigns a new value to `ThreadAssociations.txAssociations`, a field whose contents are used as a lock. The locking behavior of this function may allow this assignment to occur multiple times. > Tom's reaction on this > {quote} > I think that the bug is that there is any synchronization at all on txAssociations because it looks to be indexed by Thread.currentThread(). > {quote} > [1] https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/jts/extensions/ThreadAssociations.java#L125 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 20 09:47:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 20 Sep 2016 09:47:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2757) ThreadAssociations#add uses getKey but then it overwrites the transactions associated with the thread In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2757: ------------------------------------- Summary: ThreadAssociations#add uses getKey but then it overwrites the transactions associated with the thread Key: JBTM-2757 URL: https://issues.jboss.org/browse/JBTM-2757 Project: JBoss Transaction Manager Issue Type: Bug Components: JTS Affects Versions: 5.3.4.Final Reporter: Ondra Chaloupka Assignee: Tom Jenkinson This issue came from Tom's investigation on JBTM-2756 (which came from static code analysis). This issue points to the fact that for ThreadAssoction#add [1] tx is used as a getKey but then it overwrites the transactions associated with the thread. This seems to be a bug and need more investigation. [1] https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/jts/classes/com/arjuna/ats/jts/extensions/ThreadAssociations.java#L66? -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 20 10:00:06 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 20 Sep 2016 10:00:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2758) Static code analysis: potential lock collisions FileProcessId#getpid - interned string used as a lock In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2758: ------------------------------------- Summary: Static code analysis: potential lock collisions FileProcessId#getpid - interned string used as a lock Key: JBTM-2758 URL: https://issues.jboss.org/browse/JBTM-2758 Project: JBoss Transaction Manager Issue Type: Bug Components: Transaction Core Affects Versions: 5.3.4.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Minor _CID-17581_: Bad choice of lock object - Potential lock collisions at class `FileProcessId`[6] method `getpid` with error message {quote} Interned string as a lock may cause deadlocks or performance problems if a library also uses the interned string as a lock. ?string_literal: The string literal "0x" is an interned string. ?interned_string_lock: Locking on an interned string can cause unexpected locking collisions with third party code. ?Instead of using "0x" as a lock, create a final field of type Object which is only used as a lock. {quote} See Java examples at Coverity page [7]. The explanation there is that ? String literals are centrally interned and could also be locked on by a library, causing you to potentially have deadlocks or lock collisions with other code. There are several places [8] on net when searching for `java synchronzation on strings`. [6] https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/utils/FileProcessId.java#L63 [7] https://ondemand.coverity.com/reference/7.6.1/en/coverity#N5069A [8] http://www.javalobby.org/java/forums/t96352.html -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 20 10:02:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 20 Sep 2016 10:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2759) Static code analysis: potential lock collisions BaseTransactionManagerDelegate#findLock - interned string used as a lock In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2759: ------------------------------------- Summary: Static code analysis: potential lock collisions BaseTransactionManagerDelegate#findLock - interned string used as a lock Key: JBTM-2759 URL: https://issues.jboss.org/browse/JBTM-2759 Project: JBoss Transaction Manager Issue Type: Bug Components: JTS Affects Versions: 5.3.4.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Priority: Minor _CID-17577_: Bad choice of lock object - Potential lock collisions at class {{BaseTransactionManagerDelegate}}[9] at method {{findLock}}. {quote} string_literal: The string literal "__LOCKS_MAP" is an interned string. ? interned_string_lock: Locking on an interned string can cause unexpected locking collisions with third party code. ? Instead of using "__LOCKS_MAP" as a lock, create a final field of type Object which is only used as a lock. {quote} Explanation at description of JBTM-2758 [9] https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/integration/src/main/java/com/arjuna/ats/jbossatx/BaseTransactionManagerDelegate.java#L350 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 21 02:41:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 21 Sep 2016 02:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2759) Static code analysis: potential lock collisions BaseTransactionManagerDelegate#findLock - interned string used as a lock In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1071 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Static code analysis: potential lock collisions BaseTransactionManagerDelegate#findLock - interned string used as a lock > ------------------------------------------------------------------------------------------------------------------------ > > Key: JBTM-2759 > URL: https://issues.jboss.org/browse/JBTM-2759 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > _CID-17577_: Bad choice of lock object - Potential lock collisions > at class {{BaseTransactionManagerDelegate}}[9] at method {{findLock}}. > {quote} > string_literal: The string literal "__LOCKS_MAP" is an interned string. > ? interned_string_lock: Locking on an interned string can cause unexpected locking collisions with third party code. > ? Instead of using "__LOCKS_MAP" as a lock, create a final field of type Object which is only used as a lock. > {quote} > Explanation at description of JBTM-2758 > [9] https://github.com/jbosstm/narayana/blob/master/ArjunaJTS/integration/src/main/java/com/arjuna/ats/jbossatx/BaseTransactionManagerDelegate.java#L350 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 21 02:41:00 2016 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 21 Sep 2016 02:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2758) Static code analysis: potential lock collisions FileProcessId#getpid - interned string used as a lock In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1071 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Static code analysis: potential lock collisions FileProcessId#getpid - interned string used as a lock > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2758 > URL: https://issues.jboss.org/browse/JBTM-2758 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core > Affects Versions: 5.3.4.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > _CID-17581_: Bad choice of lock object - Potential lock collisions > at class `FileProcessId`[6] method `getpid` with error message > {quote} > Interned string as a lock may cause deadlocks or performance problems if a library also uses the interned string as a lock. > ?string_literal: The string literal "0x" is an interned string. > ?interned_string_lock: Locking on an interned string can cause unexpected locking collisions with third party code. > ?Instead of using "0x" as a lock, create a final field of type Object which is only used as a lock. > {quote} > See Java examples at Coverity page [7]. The explanation there is that > ? String literals are centrally interned and could also be locked on by a > library, causing you to potentially have deadlocks or lock collisions > with other code. > There are several places [8] on net when searching for `java synchronzation on strings`. > [6] https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/utils/FileProcessId.java#L63 > [7] https://ondemand.coverity.com/reference/7.6.1/en/coverity#N5069A > [8] http://www.javalobby.org/java/forums/t96352.html -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 21 11:35:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 21 Sep 2016 11:35:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #15 in GitHub --------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Reopened) > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > When EJB remoting sees an incomming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 21 15:47:00 2016 From: issues at jboss.org (davidkarlsen (JIRA)) Date: Wed, 21 Sep 2016 15:47:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2676) Allow TransactionalDriver connection.close() in afterCompletion In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13296715#comment-13296715 ] davidkarlsen commented on JBTM-2676: ------------------------------------ Are there any known workarounds in the way to configure spring+narayana+hibernate? > Allow TransactionalDriver connection.close() in afterCompletion > --------------------------------------------------------------- > > Key: JBTM-2676 > URL: https://issues.jboss.org/browse/JBTM-2676 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Hibernate closes connections in afterCompletion. However, TransactionalDriver requires transaction to be in an active state in order to delist resource. > See new JTA and Hibernate standalone quickstart for reproduction. > {code} > 2016-06-15 02:21:07,413 [main] WARN com.arjuna.ats.jta - ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization at e4b6f47 with exception > org.hibernate.exception.GenericJDBCException: Unable to release JDBC Connection > at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:111) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:97) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:172) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:135) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:290) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransactionCompletion(JdbcCoordinatorImpl.java:490) > at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.afterCompletion(JtaTransactionCoordinatorImpl.java:345) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.doAfterCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:60) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl.afterCompletion(SynchronizationCallbackCoordinatorTrackingImpl.java:72) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.afterCompletion(RegisteredSynchronization.java:44) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:473) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:127) > at com.arjuna.ats.arjuna.AtomicAction.abort(AtomicAction.java:186) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1282) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143) > at org.jboss.narayana.quickstart.jta.TestCase.testRollback(TestCase.java:145) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > Caused by: java.sql.SQLException: ARJUNA017020: Transaction is not active on the thread! > at com.arjuna.ats.internal.jdbc.ConnectionImple.checkTransaction(ConnectionImple.java:1071) > at com.arjuna.ats.internal.jdbc.ConnectionImple.isClosed(ConnectionImple.java:417) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:166) > ... 45 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 21 16:04:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 21 Sep 2016 16:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2676) Allow TransactionalDriver connection.close() in afterCompletion In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13296720#comment-13296720 ] Tom Jenkinson commented on JBTM-2676: ------------------------------------- Unfortunately not to my knowledge, except to run with my PR till we get it merged. > Allow TransactionalDriver connection.close() in afterCompletion > --------------------------------------------------------------- > > Key: JBTM-2676 > URL: https://issues.jboss.org/browse/JBTM-2676 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Hibernate closes connections in afterCompletion. However, TransactionalDriver requires transaction to be in an active state in order to delist resource. > See new JTA and Hibernate standalone quickstart for reproduction. > {code} > 2016-06-15 02:21:07,413 [main] WARN com.arjuna.ats.jta - ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization at e4b6f47 with exception > org.hibernate.exception.GenericJDBCException: Unable to release JDBC Connection > at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:111) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:97) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:172) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:135) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:290) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransactionCompletion(JdbcCoordinatorImpl.java:490) > at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.afterCompletion(JtaTransactionCoordinatorImpl.java:345) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.doAfterCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:60) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl.afterCompletion(SynchronizationCallbackCoordinatorTrackingImpl.java:72) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.afterCompletion(RegisteredSynchronization.java:44) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:473) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:127) > at com.arjuna.ats.arjuna.AtomicAction.abort(AtomicAction.java:186) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1282) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143) > at org.jboss.narayana.quickstart.jta.TestCase.testRollback(TestCase.java:145) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > Caused by: java.sql.SQLException: ARJUNA017020: Transaction is not active on the thread! > at com.arjuna.ats.internal.jdbc.ConnectionImple.checkTransaction(ConnectionImple.java:1071) > at com.arjuna.ats.internal.jdbc.ConnectionImple.isClosed(ConnectionImple.java:417) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:166) > ... 45 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 22 08:42:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 22 Sep 2016 08:42:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2753) Method end on PGXAConnection has been called twice In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2753: ----------------------------------- Assignee: Tom Jenkinson > Method end on PGXAConnection has been called twice > -------------------------------------------------- > > Key: JBTM-2753 > URL: https://issues.jboss.org/browse/JBTM-2753 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.0.Final > Environment: Wildfly 8 > Reporter: Florian M?lot > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > End method from PGXAConnection has been called twice when an EJB called another EJB to get data from psql database (9.2.5) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 22 08:42:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 22 Sep 2016 08:42:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2753) Method end on PGXAConnection has been called twice In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2753: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Method end on PGXAConnection has been called twice > -------------------------------------------------- > > Key: JBTM-2753 > URL: https://issues.jboss.org/browse/JBTM-2753 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.0.Final > Environment: Wildfly 8 > Reporter: Florian M?lot > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > End method from PGXAConnection has been called twice when an EJB called another EJB to get data from psql database (9.2.5) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 22 09:32:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 22 Sep 2016 09:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2720) Allow the setting of an initial delay in PeriodRecovery In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13297167#comment-13297167 ] RH Bugzilla Integration commented on JBTM-2720: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1367187|https://bugzilla.redhat.com/show_bug.cgi?id=1367187] from MODIFIED to ON_QA > Allow the setting of an initial delay in PeriodRecovery > ------------------------------------------------------- > > Key: JBTM-2720 > URL: https://issues.jboss.org/browse/JBTM-2720 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Reporter: Matthew Robson > Assignee: Tom Jenkinson > Fix For: 4.17.35, 5.2.18.Final, 5.3.4.Final > > > Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers. > In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster. > Periodic Recovery currently leverages 2 properties: > > > > > The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 22 09:36:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 22 Sep 2016 09:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2709) ObjectStoreBrowser cannot cope with JDBC store on Windows In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13297198#comment-13297198 ] RH Bugzilla Integration commented on JBTM-2709: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1356589|https://bugzilla.redhat.com/show_bug.cgi?id=1356589] from MODIFIED to ON_QA > ObjectStoreBrowser cannot cope with JDBC store on Windows > --------------------------------------------------------- > > Key: JBTM-2709 > URL: https://issues.jboss.org/browse/JBTM-2709 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.35, 5.3.4.Final > > > While testing backport of JBTM-2614 I came across the ObjStoreBrowser test. This was failing on Windows. On looking into it I saw it was because the Browser map swaps the "/" in the type name to the system file separator path. This is likely because of the file system store. I have a fix that puts the entry in both ways but it will likely need some more work so providing as an example. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 22 09:36:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 22 Sep 2016 09:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2708) Test does not close FileInputStream In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13297199#comment-13297199 ] RH Bugzilla Integration commented on JBTM-2708: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1356589|https://bugzilla.redhat.com/show_bug.cgi?id=1356589] from MODIFIED to ON_QA > Test does not close FileInputStream > ----------------------------------- > > Key: JBTM-2708 > URL: https://issues.jboss.org/browse/JBTM-2708 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 4.17.35, 5.3.4.Final > > > {code} > public XARRTestResource(String xarrHelper, File file) throws IOException { > this.xarrHelper = xarrHelper; > this.file = file; > DataInputStream fis = new DataInputStream(new FileInputStream(file)); > final int formatId = fis.readInt(); > final int gtrid_length = fis.readInt(); > final byte[] gtrid = new byte[gtrid_length]; > fis.read(gtrid, 0, gtrid_length); > final int bqual_length = fis.readInt(); > final byte[] bqual = new byte[bqual_length]; > fis.read(bqual, 0, bqual_length); > xids.put(file, new Xid() { > @Override > public byte[] getGlobalTransactionId() { > return gtrid; > } > @Override > public int getFormatId() { > return formatId; > } > @Override > public byte[] getBranchQualifier() { > return bqual; > } > }); > fis.close(); > } > {code} > Spotted while working on JBTM-2614 backport -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 22 09:36:00 2016 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 22 Sep 2016 09:36:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2614) JCA TransactionImporter should be thread safe In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13297200#comment-13297200 ] RH Bugzilla Integration commented on JBTM-2614: ----------------------------------------------- Vladimir Dosoudil changed the Status of [bug 1356589|https://bugzilla.redhat.com/show_bug.cgi?id=1356589] from MODIFIED to ON_QA > JCA TransactionImporter should be thread safe > --------------------------------------------- > > Key: JBTM-2614 > URL: https://issues.jboss.org/browse/JBTM-2614 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.2.12.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 4.17.35, 5.2.13.Final > > > I have a unit test that shows there's a race condition (first observed by [~dmlloyd]) in com.arjuna.ats.internal.jta.transaction.arjunacore.jca.TransactionImporterImple#importTransaction(javax.transaction.xa.Xid, int). > If two threads call this method at the same time, two separate transaction objects may be created. Here's the sequence of events: > T1: call importTransaction for XID1 > T2: call importTransaction for XID1 > T1: getImportedTransaction returns null > T2: getImportedTransaction returns null > T1: create new transaction, add to map > T2: create new transaction, add to map (overwriting T1's) > There is nothing in the documentation to indicate that this is not a valid situation or that access to the TransactionImporter has to be single-threaded in any way. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 27 02:07:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 27 Sep 2016 02:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2480) Provide documentation of how to integrate with Karaf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Amos Feng created pull request #40 in GitHub -------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Coding In Progress) > Provide documentation of how to integrate with Karaf > ---------------------------------------------------- > > Key: JBTM-2480 > URL: https://issues.jboss.org/browse/JBTM-2480 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > This should include recovery information -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 27 05:35:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 27 Sep 2016 05:35:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2747) Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2747: ----------------------------------- Assignee: Tom Jenkinson > Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions > --------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2747 > URL: https://issues.jboss.org/browse/JBTM-2747 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > The previous example relied upon the "transport" piece maintaining a list of root transactions it had seen. It is actually possible to use the existing list from the TransactionImple -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 27 05:35:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 27 Sep 2016 05:35:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2747) Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2747: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions > --------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2747 > URL: https://issues.jboss.org/browse/JBTM-2747 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > The previous example relied upon the "transport" piece maintaining a list of root transactions it had seen. It is actually possible to use the existing list from the TransactionImple -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 27 05:40:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 27 Sep 2016 05:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2747) Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reopened JBTM-2747: --------------------------------- > Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions > --------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2747 > URL: https://issues.jboss.org/browse/JBTM-2747 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > The previous example relied upon the "transport" piece maintaining a list of root transactions it had seen. It is actually possible to use the existing list from the TransactionImple -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 27 05:40:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 27 Sep 2016 05:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2747) Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2747. ------------------------------- Resolution: Duplicate Issue Subsumed within JBTM-2749 > Modify the SimpleIsolatedServers example such that it does not need the "transport" to maintain its own map of transactions > --------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2747 > URL: https://issues.jboss.org/browse/JBTM-2747 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > The previous example relied upon the "transport" piece maintaining a list of root transactions it had seen. It is actually possible to use the existing list from the TransactionImple -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 27 05:41:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 27 Sep 2016 05:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2749: -------------------------------- Description: When EJB remoting sees an incoming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. (was: When EJB remoting sees an incomming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node.) > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > When EJB remoting sees an incoming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 27 06:28:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 27 Sep 2016 06:28:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2676) Allow TransactionalDriver connection.close() in afterCompletion In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2676: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Allow TransactionalDriver connection.close() in afterCompletion > --------------------------------------------------------------- > > Key: JBTM-2676 > URL: https://issues.jboss.org/browse/JBTM-2676 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > Hibernate closes connections in afterCompletion. However, TransactionalDriver requires transaction to be in an active state in order to delist resource. > See new JTA and Hibernate standalone quickstart for reproduction. > {code} > 2016-06-15 02:21:07,413 [main] WARN com.arjuna.ats.jta - ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization at e4b6f47 with exception > org.hibernate.exception.GenericJDBCException: Unable to release JDBC Connection > at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:111) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:97) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:172) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:135) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:290) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransactionCompletion(JdbcCoordinatorImpl.java:490) > at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.afterCompletion(JtaTransactionCoordinatorImpl.java:345) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.doAfterCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:60) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl.afterCompletion(SynchronizationCallbackCoordinatorTrackingImpl.java:72) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.afterCompletion(RegisteredSynchronization.java:44) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:473) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:127) > at com.arjuna.ats.arjuna.AtomicAction.abort(AtomicAction.java:186) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1282) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143) > at org.jboss.narayana.quickstart.jta.TestCase.testRollback(TestCase.java:145) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > Caused by: java.sql.SQLException: ARJUNA017020: Transaction is not active on the thread! > at com.arjuna.ats.internal.jdbc.ConnectionImple.checkTransaction(ConnectionImple.java:1071) > at com.arjuna.ats.internal.jdbc.ConnectionImple.isClosed(ConnectionImple.java:417) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:166) > ... 45 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 27 06:28:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 27 Sep 2016 06:28:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2676) Allow TransactionalDriver connection.close() in afterCompletion In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-2676: ----------------------------------- Assignee: Tom Jenkinson (was: Gytis Trikleris) > Allow TransactionalDriver connection.close() in afterCompletion > --------------------------------------------------------------- > > Key: JBTM-2676 > URL: https://issues.jboss.org/browse/JBTM-2676 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.next > > > Hibernate closes connections in afterCompletion. However, TransactionalDriver requires transaction to be in an active state in order to delist resource. > See new JTA and Hibernate standalone quickstart for reproduction. > {code} > 2016-06-15 02:21:07,413 [main] WARN com.arjuna.ats.jta - ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization at e4b6f47 with exception > org.hibernate.exception.GenericJDBCException: Unable to release JDBC Connection > at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:111) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:97) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:172) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:135) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:290) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransactionCompletion(JdbcCoordinatorImpl.java:490) > at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.afterCompletion(JtaTransactionCoordinatorImpl.java:345) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.doAfterCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:60) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl.afterCompletion(SynchronizationCallbackCoordinatorTrackingImpl.java:72) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.afterCompletion(RegisteredSynchronization.java:44) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:473) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:127) > at com.arjuna.ats.arjuna.AtomicAction.abort(AtomicAction.java:186) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1282) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143) > at org.jboss.narayana.quickstart.jta.TestCase.testRollback(TestCase.java:145) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > Caused by: java.sql.SQLException: ARJUNA017020: Transaction is not active on the thread! > at com.arjuna.ats.internal.jdbc.ConnectionImple.checkTransaction(ConnectionImple.java:1071) > at com.arjuna.ats.internal.jdbc.ConnectionImple.isClosed(ConnectionImple.java:417) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:166) > ... 45 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Tue Sep 27 17:05:00 2016 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 27 Sep 2016 17:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2728) Add a forget operation to the tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1074 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Add a forget operation to the tooling > ------------------------------------- > > Key: JBTM-2728 > URL: https://issues.jboss.org/browse/JBTM-2728 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Tooling > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The tooling provides two features for dealing with heuristic participants: > * a recover command that will move it back into the prepared state if the admin thinks a second prepare attempt is likely to succeed; > * a delete operation if the admin thinks it safe to do so; > > In the case of XA resources we also need a forget operation which will trigger the resource adaptor to clean up its end instead of relying on the admin to use tooling provided by the RA to clean up. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 28 02:17:00 2016 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 28 Sep 2016 02:17:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2480) Provide documentation of how to integrate with Karaf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-2480: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Provide documentation of how to integrate with Karaf > ---------------------------------------------------- > > Key: JBTM-2480 > URL: https://issues.jboss.org/browse/JBTM-2480 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > This should include recovery information -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 28 05:02:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 28 Sep 2016 05:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2760) SPI to check if JTA or JTS transaction is active during graceful shutdown In-Reply-To: References: Message-ID: Gytis Trikleris created JBTM-2760: ------------------------------------- Summary: SPI to check if JTA or JTS transaction is active during graceful shutdown Key: JBTM-2760 URL: https://issues.jboss.org/browse/JBTM-2760 Project: JBoss Transaction Manager Issue Type: Feature Request Components: SPI Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Critical During graceful shutdown EJB subsystem should check with transaction subsystem if request should be allowed in. Only requests participating in an existing transaction are permitted. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 28 05:05:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 28 Sep 2016 05:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2760) SPI to check if JTA or JTS transaction is active during graceful shutdown In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JBTM-2760 started by Gytis Trikleris. --------------------------------------------- > SPI to check if JTA or JTS transaction is active during graceful shutdown > ------------------------------------------------------------------------- > > Key: JBTM-2760 > URL: https://issues.jboss.org/browse/JBTM-2760 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: SPI > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Critical > > During graceful shutdown EJB subsystem should check with transaction subsystem if request should be allowed in. Only requests participating in an existing transaction are permitted. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 28 06:13:01 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 28 Sep 2016 06:13:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2760) SPI to check if JTA or JTS transaction is active during graceful shutdown In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gytis Trikleris closed JBTM-2760. --------------------------------- Resolution: Rejected Apparently this can already be achieved by using current SPI https://github.com/jbosstm/jboss-transaction-spi/blob/master/src/main/java/org/jboss/tm/ExtendedJBossXATerminator.java#L67. In WildFly it can be injected with this name https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java/org/jboss/as/txn/service/TxnServices.java#L40 > SPI to check if JTA or JTS transaction is active during graceful shutdown > ------------------------------------------------------------------------- > > Key: JBTM-2760 > URL: https://issues.jboss.org/browse/JBTM-2760 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: SPI > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Critical > > During graceful shutdown EJB subsystem should check with transaction subsystem if request should be allowed in. Only requests participating in an existing transaction are permitted. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Wed Sep 28 06:43:00 2016 From: issues at jboss.org (Gytis Trikleris (JIRA)) Date: Wed, 28 Sep 2016 06:43:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2760) SPI to check if JTA or JTS transaction is active during graceful shutdown In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13299560#comment-13299560 ] Gytis Trikleris commented on JBTM-2760: --------------------------------------- WildFly service exposes JBossXATerminator and it needs to be casted to ExtendedJBossXATerminator. We should add a new service which would expose ExtendedJBossXATerminator, but that doesn't require any changes in the SPI. > SPI to check if JTA or JTS transaction is active during graceful shutdown > ------------------------------------------------------------------------- > > Key: JBTM-2760 > URL: https://issues.jboss.org/browse/JBTM-2760 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: SPI > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Critical > > During graceful shutdown EJB subsystem should check with transaction subsystem if request should be allowed in. Only requests participating in an existing transaction are permitted. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 08:43:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 08:43:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2701: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done PR was merged > Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system > --------------------------------------------------------------------------------------------- > > Key: JBTM-2701 > URL: https://issues.jboss.org/browse/JBTM-2701 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Affects Versions: 4.17.33 > Environment: JBoss EA P6.4.8 > Reporter: Tom Ross > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default). > The following signature can be observed in the log file: > {noformat} > 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3 > 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra > > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3 > {noformat} > It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2743) Blacktie integration-tests TestTPCancel hang In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2743. ------------------------------- > Blacktie integration-tests TestTPCancel hang > -------------------------------------------- > > Key: JBTM-2743 > URL: https://issues.jboss.org/browse/JBTM-2743 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Labels: vc9x32 > Fix For: 5.3.5.Final > > > The root cause is that the server is blocking in the thread which is connecting to the call back server in the java client. It looks like the java client has been shutdown but the apr_pollset_poll in the server HybridSocketEndpointQueue.cxx can not get the socket status and it is running infinitely. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2734) EIS can't recover inflowed transaction when heuristic outcome happens and tooling is used to reset the participant to prepared In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2734. ------------------------------- > EIS can't recover inflowed transaction when heuristic outcome happens and tooling is used to reset the participant to prepared > ------------------------------------------------------------------------------------------------------------------------------ > > Key: JBTM-2734 > URL: https://issues.jboss.org/browse/JBTM-2734 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Tom Jenkinson > Priority: Critical > Fix For: 5.3.5.Final > > > For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way > # prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB. > # transaction is marked to have heuristic result and manual intervention is necessary > # user calls {{recover}} for participant at such state and its state is changed to _prepared_ > # replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store > This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be > # EIS propagates EIS TX to Narayana > # enlisting XAR in Narayana subordinate TX > # committing EIS TX > ## It commits Narayana subordinate TX > # XAR in Narayana TX returns RMERR > # Narayana returns XA_HEURMIX > # calling the Narayana tooling op {{recover}} to move the heuristic back to prepared > # EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet > # EIS should call Narayana via XATerminator::recover() > ## getting back an Xid that matches to Narayana subordinate TX > # EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid) > (_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_) > The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2730) Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2730. ------------------------------- > Moving txn datastore to machine with different default encoding can cause in-doubt participants not being recovered > ------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2730 > URL: https://issues.jboss.org/browse/JBTM-2730 > Project: JBoss Transaction Manager > Issue Type: Bug > Affects Versions: 5.3.3.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.3.5.Final > > > Narayana uses system default encoding when encode and decode data for object store. This could be a trouble if user uses non-ASCII characters for node identifier and object store is meanwhile moved between machines with different default encodings. > I've currently revealed two cases which could cause a trouble: > * node id set as {{...}} _(there is needed to use some characters which are encoded in UTF-8 as more bytes characters)_ will let container being started for encoding ISO-8859-1 and won't be started for encoding UTF-8. That's when configuration moved from ISO-8859-1 machine to UTF-8 machine when the another machine will be expected to finish recovery of some failed txn the second machine fails to start. (sure, workaround is to set jvm default encoding via parameter {{-Dfile.encoding}}) > * node id set to {{kula?ou?k?}}, whole eap installation moved from one machine with ISO-8859-1 to machine with default encoding set to UTF-8. Txn object store is copied too for second machine finishing in-doubt transaction by recovery. The second machine won't finish transactions which depends on node identifer check (bottom-up recovery) as node id will be decoded differently than it was understood at the first machine. > This issue was found by using static code analysis and reacts to report message > {code} > 21994 Dm: Dubious method used In org.jboss.narayana.osgi.jta.internal.ObjStoreBrowserImpl.ObjStoreBrowserImpl (com.arjuna.ats.arjuna.tools.osb.mbean.ObjStoreBrowser): Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2726) Replace deprecated OutputCapture in Spring Boot quickstart test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2726. ------------------------------- > Replace deprecated OutputCapture in Spring Boot quickstart test > --------------------------------------------------------------- > > Key: JBTM-2726 > URL: https://issues.jboss.org/browse/JBTM-2726 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.3.5.Final > > > Replace deprecated org.springframework.boot.test.OutputCapture with org.springframework.boot.test.rule.OutputCapture. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2723) Upgrade the apr to 1.5 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2723. ------------------------------- > Upgrade the apr to 1.5 > ---------------------- > > Key: JBTM-2723 > URL: https://issues.jboss.org/browse/JBTM-2723 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.3.5.Final > > > This is to provide the basis of JBTM-2719. APR now provides a method to wakeup waiting pools which should be useful. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:03 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2725. ------------------------------- > Race condition in ControlWrapper > -------------------------------- > > Key: JBTM-2725 > URL: https://issues.jboss.org/browse/JBTM-2725 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Tomasz Adamski > Assignee: Tomasz Adamski > Fix For: 5.3.5.Final > > > I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:04 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2719) tpcall get three seconds delay in the fooapp quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2719. ------------------------------- > tpcall get three seconds delay in the fooapp quickstart > ------------------------------------------------------- > > Key: JBTM-2719 > URL: https://issues.jboss.org/browse/JBTM-2719 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.3.5.Final > > > The apr_pollset_poll in HybridSocketEndpointQueue.cxx Line 392 is blocking and timing out after 3 second. It is the root cause for the tpcall delaying. > So it should try to wake up the polling in non-conversation session while disconnect -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:04 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2704) Compensations framework cannot instantiate bean from ear archive In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2704. ------------------------------- > Compensations framework cannot instantiate bean from ear archive > ---------------------------------------------------------------- > > Key: JBTM-2704 > URL: https://issues.jboss.org/browse/JBTM-2704 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.3.5.Final > > > BeanManagerUtil is using CDI BeanManager to instantiate classes from the deployment to be used by the compensations framework. It works fine with war and jar archives, because all deployment classes are accessible for the root bean manager. However, ear archives have multiple bean managers and some classes cannot be accessed. > Martin Kouba has provided a workaround for this on Weld forum by using weld-core to get the correct bean manager. > It would be better to find a solution for this without adding a direct dependency on weld-core and instead injecting the correct bean manager once by the subsystem. However, if that is not possible, we should use the provided workaround. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:04 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2701) Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2701. ------------------------------- > Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system > --------------------------------------------------------------------------------------------- > > Key: JBTM-2701 > URL: https://issues.jboss.org/browse/JBTM-2701 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Affects Versions: 4.17.33 > Environment: JBoss EA P6.4.8 > Reporter: Tom Ross > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.3.5.Final > > > The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default). > The following signature can be observed in the log file: > {noformat} > 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3 > 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra > > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3 > {noformat} > It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:04 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2676) Allow TransactionalDriver connection.close() in afterCompletion In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2676. ------------------------------- > Allow TransactionalDriver connection.close() in afterCompletion > --------------------------------------------------------------- > > Key: JBTM-2676 > URL: https://issues.jboss.org/browse/JBTM-2676 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transactional Driver > Reporter: Gytis Trikleris > Assignee: Tom Jenkinson > Fix For: 5.3.5.Final > > > Hibernate closes connections in afterCompletion. However, TransactionalDriver requires transaction to be in an active state in order to delist resource. > See new JTA and Hibernate standalone quickstart for reproduction. > {code} > 2016-06-15 02:21:07,413 [main] WARN com.arjuna.ats.jta - ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization at e4b6f47 with exception > org.hibernate.exception.GenericJDBCException: Unable to release JDBC Connection > at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:111) > at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:97) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:172) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:135) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:290) > at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransactionCompletion(JdbcCoordinatorImpl.java:490) > at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.afterCompletion(JtaTransactionCoordinatorImpl.java:345) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.doAfterCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:60) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl.afterCompletion(SynchronizationCallbackCoordinatorTrackingImpl.java:72) > at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.afterCompletion(RegisteredSynchronization.java:44) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:473) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.cancel(TwoPhaseCoordinator.java:127) > at com.arjuna.ats.arjuna.AtomicAction.abort(AtomicAction.java:186) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.rollbackAndDisassociate(TransactionImple.java:1282) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.rollback(BaseTransaction.java:143) > at org.jboss.narayana.quickstart.jta.TestCase.testRollback(TestCase.java:145) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) > at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.run(ParentRunner.java:309) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > Caused by: java.sql.SQLException: ARJUNA017020: Transaction is not active on the thread! > at com.arjuna.ats.internal.jdbc.ConnectionImple.checkTransaction(ConnectionImple.java:1071) > at com.arjuna.ats.internal.jdbc.ConnectionImple.isClosed(ConnectionImple.java:417) > at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:166) > ... 45 more > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:04 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2671) TXBridge quickstart execution steps are inaccurate In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2671. ------------------------------- > TXBridge quickstart execution steps are inaccurate > -------------------------------------------------- > > Key: JBTM-2671 > URL: https://issues.jboss.org/browse/JBTM-2671 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator, TxBridge, XTS > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.3.5.Final > > > Execution steps for both wsat-jta-multi_hop and wsat-jta-multi_service quickstarts tells to start WildFly in one console and then execute the test with managed Arquillian container. Which is obviously wrong. > We shouldn't suggest to start the container manually, but only use the managed container. > Also, it might be good to not redirect output to the file, but instead print it directly and use egrep as showed in the current execution steps. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:05 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2740) Make the quickstart CI narayana.sh run script work on both clusters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2740: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Make the quickstart CI narayana.sh run script work on both clusters > ------------------------------------------------------------------- > > Key: JBTM-2740 > URL: https://issues.jboss.org/browse/JBTM-2740 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The script does not run on the NCL cluster most likely due to hard coded paths. > Fixing this will be useful because the current config hard codes which set of quickstarts to run (which is not maintainable as we add and remove quickstarts). -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:05 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2749: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > When EJB remoting sees an incoming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:05 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2669) Refactor "impl" package in compensations module to "internal" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2669. ------------------------------- > Refactor "impl" package in compensations module to "internal" > ------------------------------------------------------------- > > Key: JBTM-2669 > URL: https://issues.jboss.org/browse/JBTM-2669 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.3.5.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:05 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2480) Provide documentation of how to integrate with Karaf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2480. ------------------------------- > Provide documentation of how to integrate with Karaf > ---------------------------------------------------- > > Key: JBTM-2480 > URL: https://issues.jboss.org/browse/JBTM-2480 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Minor > Fix For: 5.3.5.Final > > > This should include recovery information -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:05 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2755) Allow btadmin to load servers from 127.0.0.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2755: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Allow btadmin to load servers from 127.0.0.1 > -------------------------------------------- > > Key: JBTM-2755 > URL: https://issues.jboss.org/browse/JBTM-2755 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > This means that when we add new nodes we don't have to add to the test each time -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2754) Class not found in JCA Tomcat quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2754. ------------------------------- > Class not found in JCA Tomcat quickstart > ---------------------------------------- > > Key: JBTM-2754 > URL: https://issues.jboss.org/browse/JBTM-2754 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.3.5.Final > > > {code} > ------------------------------------------------------------------------------- > Test set: org.jboss.narayana.quickstart.jca.model.CustomerDAOTest > ------------------------------------------------------------------------------- > Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 1.125 sec <<< FAILURE! > org.jboss.narayana.quickstart.jca.model.CustomerDAOTest Time elapsed: 0 sec <<< ERROR! > com.github.fungal.spi.deployers.DeployException: Deployment file:/C:/hudson/workspace/narayana-quickstarts-catelyn/jca-and-tomcat/target/classes/transaction.xml failed > at com.github.fungal.impl.DeploymentDeployer.deploy(DeploymentDeployer.java:157) > at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:144) > at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:82) > at org.jboss.jca.embedded.EmbeddedJCA.deploy(EmbeddedJCA.java:313) > at org.jboss.jca.embedded.EmbeddedJCA.startup(EmbeddedJCA.java:122) > at org.jboss.narayana.quickstart.jca.common.AbstractTest.beforeClass(AbstractTest.java:52) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > Caused by: com.github.fungal.spi.deployers.DeployException: Installing bean XATerminator > at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:200) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NoClassDefFoundError: org/jboss/tm/ExtendedJBossXATerminator > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:760) > at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) > at java.net.URLClassLoader.access$100(URLClassLoader.java:73) > at java.net.URLClassLoader$1.run(URLClassLoader.java:368) > at java.net.URLClassLoader$1.run(URLClassLoader.java:362) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:361) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at com.github.fungal.impl.classloader.ParentFirstClassLoader.loadClass(ParentFirstClassLoader.java:67) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:348) > at com.github.fungal.impl.BeanDeployer.createBean(BeanDeployer.java:318) > at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:186) > ... 5 more > Caused by: java.lang.ClassNotFoundException: org.jboss.tm.ExtendedJBossXATerminator > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 22 more > org.jboss.narayana.quickstart.jca.model.CustomerDAOTest Time elapsed: 0 sec <<< ERROR! > java.lang.IllegalStateException: Container not started > at org.jboss.jca.embedded.EmbeddedJCA.undeploy(EmbeddedJCA.java:327) > at org.jboss.narayana.quickstart.jca.common.AbstractTest.afterClass(AbstractTest.java:59) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > {code} > {code} > ------------------------------------------------------------------------------- > Test set: org.jboss.narayana.quickstart.jca.xa.XAResourcesTest > ------------------------------------------------------------------------------- > Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.047 sec <<< FAILURE! > org.jboss.narayana.quickstart.jca.xa.XAResourcesTest Time elapsed: 0.079 sec <<< ERROR! > com.github.fungal.spi.deployers.DeployException: Deployment file:/C:/hudson/workspace/narayana-quickstarts-catelyn/jca-and-tomcat/target/classes/transaction.xml failed > at com.github.fungal.impl.DeploymentDeployer.deploy(DeploymentDeployer.java:157) > at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:144) > at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:82) > at org.jboss.jca.embedded.EmbeddedJCA.deploy(EmbeddedJCA.java:313) > at org.jboss.jca.embedded.EmbeddedJCA.startup(EmbeddedJCA.java:122) > at org.jboss.narayana.quickstart.jca.common.AbstractTest.beforeClass(AbstractTest.java:52) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:27) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > Caused by: com.github.fungal.spi.deployers.DeployException: Installing bean XATerminator > at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:200) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.NoClassDefFoundError: org/jboss/tm/ExtendedJBossXATerminator > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClass(ClassLoader.java:760) > at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) > at java.net.URLClassLoader.access$100(URLClassLoader.java:73) > at java.net.URLClassLoader$1.run(URLClassLoader.java:368) > at java.net.URLClassLoader$1.run(URLClassLoader.java:362) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(URLClassLoader.java:361) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > at com.github.fungal.impl.classloader.ParentFirstClassLoader.loadClass(ParentFirstClassLoader.java:67) > at com.github.fungal.impl.classloader.ParentFirstClassLoader.loadClass(ParentFirstClassLoader.java:67) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:348) > at com.github.fungal.impl.BeanDeployer.createBean(BeanDeployer.java:318) > at com.github.fungal.impl.BeanDeployer.run(BeanDeployer.java:186) > ... 5 more > Caused by: java.lang.ClassNotFoundException: org.jboss.tm.ExtendedJBossXATerminator > at java.net.URLClassLoader.findClass(URLClassLoader.java:381) > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > ... 23 more > org.jboss.narayana.quickstart.jca.xa.XAResourcesTest Time elapsed: 0.079 sec <<< ERROR! > java.lang.IllegalStateException: Container not started > at org.jboss.jca.embedded.EmbeddedJCA.undeploy(EmbeddedJCA.java:327) > at org.jboss.narayana.quickstart.jca.common.AbstractTest.afterClass(AbstractTest.java:59) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:36) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:35) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:115) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:97) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103) > at com.sun.proxy.$Proxy0.invoke(Unknown Source) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2753) Method end on PGXAConnection has been called twice In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2753. ------------------------------- > Method end on PGXAConnection has been called twice > -------------------------------------------------- > > Key: JBTM-2753 > URL: https://issues.jboss.org/browse/JBTM-2753 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.0.Final > Environment: Wildfly 8 > Reporter: Florian M?lot > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.3.5.Final > > > End method from PGXAConnection has been called twice when an EJB called another EJB to get data from psql database (9.2.5) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2748) Prevent JTS bottom-up recovery from rolling back prepared inflowed JCA transactions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2748. ------------------------------- > Prevent JTS bottom-up recovery from rolling back prepared inflowed JCA transactions > ----------------------------------------------------------------------------------- > > Key: JBTM-2748 > URL: https://issues.jboss.org/browse/JBTM-2748 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA, JTS, Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.3.5.Final > > > There exists a defect that if a recovering JVM does the following steps: > doRecoveryScan() > waitForOrphanInterval() > doRecoveryScan() > *Before* XATerminator::recover is called in the root coordinator then bottom-up recovery will be told there is NoTransaction which is infers as a rollback. > I saw two options, one was to have TransactionCacheItem try to peek in the objectstore for ServerTransaction/JCA classes. The alternative is to add a new recovery module that can load the ServerTransaction/JCA classes periodically so the transaction won't be lost. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:02 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2744) Warning message show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2744. ------------------------------- > Warning message show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI > -------------------------------------------------------------------------------------------------- > > Key: JBTM-2744 > URL: https://issues.jboss.org/browse/JBTM-2744 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.3.5.Final > > > The warning message are > {code} > 00:06:48,719 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 69) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieStompAdministrationService message-driven bean. It will be handled as NOT_SUPPORTED. > 00:06:48,721 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 67) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieAdminServiceXATMI message-driven bean. It will be handled as NOT_SUPPORTED. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:05 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2260) BlackTie does not build on CentOS 7 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2260. ------------------------------- > BlackTie does not build on CentOS 7 > ----------------------------------- > > Key: JBTM-2260 > URL: https://issues.jboss.org/browse/JBTM-2260 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.0.4, 5.3.5.Final > > > [hudson at sansa ~]$ uname -a > Linux sansa.buildnet.ncl.jboss.com 3.10.0-123.6.3.el7.x86_64 #1 SMP Wed Aug 6 21:12:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > http://172.17.131.2/view/Narayana+BlackTie/job/narayana-jdbcobjectstore/DB_TYPE=mysql,jdk=jdk7.latest,slave=linux/101/console > {quote} > test-compile: > [mkdir] Created dir: /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [copy] Copying 6 files to /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/target/cpp-test-classes > [cc] 11 total files to be compiled. > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?virtual void TestAtmiBrokerXml::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:34:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=."); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:35:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_env()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:41:45: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:42:41: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=xmltest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_define_adminservice()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:155:47: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=wrongtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_same_service()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:167:46: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=sametest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_invalid_xml()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:179:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=invalidtest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx: In member function ?void TestAtmiBrokerXml::test_no_config()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestAtmiBrokerXml.cxx:191:56: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION_DIR=noexisttest"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:35:39: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION=linux"); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx: In member function ?virtual void TestSymbolLoader::tearDown()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSymbolLoader.cxx:42:34: warning: deprecated conversion from string constant to ?char*? [-Wwrite-strings] > [cc] putenv("BLACKTIE_CONFIGURATION="); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In function ?void* activateWaiter(apr_thread_t*, void*)?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:31:9: warning: unused variable ?ret? [-Wunused-variable] > [cc] int ret = waiter->svc(); > [cc] ^ > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx: In member function ?virtual void TestSynchronizableObject::setUp()?: > [cc] /home/hudson/workspace/narayana-jdbcobjectstore/DB_TYPE/mysql/jdk/jdk7.latest/slave/linux/blacktie/core/src/test/cpp/TestSynchronizableObject.cxx:76:6: warning: unused variable ?argc? [-Wunused-variable] > [cc] int argc = 0; > [cc] ^ > [cc] Starting link > [cc] /lib64/libaprutil-1.so.0: undefined reference to `apr_pool_pre_cleanup_register' > [cc] collect2: error: ld returned 1 exit status > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:05 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2752) Database connection on POSTGRE required max_prepared_statement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2752: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Database connection on POSTGRE required max_prepared_statement > -------------------------------------------------------------- > > Key: JBTM-2752 > URL: https://issues.jboss.org/browse/JBTM-2752 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > max_prepared_statement is required on the file (postgre.conf) to connect on pgsql base. > If this option wasn't activate, the method end is called twice on PGXAConnection > Please find below original discussion : > https://developer.jboss.org/message/958507#958507 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:06 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2738) Upgrade jboss-transaction-spi dependency to 7.3.3.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2738: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Upgrade jboss-transaction-spi dependency to 7.3.3.Final > ------------------------------------------------------- > > Key: JBTM-2738 > URL: https://issues.jboss.org/browse/JBTM-2738 > Project: JBoss Transaction Manager > Issue Type: Task > Components: SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > There is a new version of the jboss-transaction-spi which fixed a UserTransaction serialization issue. This change should not affect narayana (hence the minor priority leve) but we should be consuming the most recent release. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:06 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2739) Add a CI job for testing jboss-transaction-spi In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2739: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Add a CI job for testing jboss-transaction-spi > ---------------------------------------------- > > Key: JBTM-2739 > URL: https://issues.jboss.org/browse/JBTM-2739 > Project: JBoss Transaction Manager > Issue Type: Task > Components: SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > We need a CI job to test that narayana works with the latest jboss-transaction-spi and this should include PRs as well as master. > In addition, the two projects duplicate tests so the the duplicates need removing from narayana (but only after we have added this CI testing). > Note that jboss-transaction-spi has a test dependency on the last released stable version of narayana so that dependency would need to changed to the version of our current SNAPSHOT for these new proposed CI jobs to be useful. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:06 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2713) Investigate why a null FileLock is declared but not used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2713: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Investigate why a null FileLock is declared but not used > -------------------------------------------------------- > > Key: JBTM-2713 > URL: https://issues.jboss.org/browse/JBTM-2713 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > It is not assigned but later on it is checked for null and if not then released: > https://github.com/jbosstm/narayana/blob/29270942f17cc553ad1497a41f60fce12e784fb6/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/LogStore.java#L734 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:06 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2728) Add a forget operation to the tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2728: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Add a forget operation to the tooling > ------------------------------------- > > Key: JBTM-2728 > URL: https://issues.jboss.org/browse/JBTM-2728 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Tooling > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The tooling provides two features for dealing with heuristic participants: > * a recover command that will move it back into the prepared state if the admin thinks a second prepare attempt is likely to succeed; > * a delete operation if the admin thinks it safe to do so; > > In the case of XA resources we also need a forget operation which will trigger the resource adaptor to clean up its end instead of relying on the admin to use tooling provided by the RA to clean up. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:06 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2705) Investigate alternatives to encoding recovery data in RecoveryCoordinator IORs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2705: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Investigate alternatives to encoding recovery data in RecoveryCoordinator IORs > ------------------------------------------------------------------------------ > > Key: JBTM-2705 > URL: https://issues.jboss.org/browse/JBTM-2705 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTS > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > During JTS resource enlistment we create a RecoveryCoordinator IOR and embed recovery information in the ObjectKey part. This is not a portable solution since we need to use ORB vendor specific APIs to modify the ObjectKey. It would be preferable if we could use something that is in the CORBA specs that will work for all ORBs such as Portable Intercpeors (http://www.omg.org/cgi-bin/doc?ptc/2001-03-04). > Note that there is no current solution for IBM orb. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:06 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2688) Message was not delivered to the queue in Spring Boot QS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2688: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Message was not delivered to the queue in Spring Boot QS > -------------------------------------------------------- > > Key: JBTM-2688 > URL: https://issues.jboss.org/browse/JBTM-2688 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.next > > > {code} > ------------------------------------------------------------------------------- > Test set: org.jboss.narayana.quickstart.spring.QuickstartApplicationTests > ------------------------------------------------------------------------------- > Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 11.443 sec <<< FAILURE! > testCommit(org.jboss.narayana.quickstart.spring.QuickstartApplicationTests) Time elapsed: 2.43 sec <<< FAILURE! > java.lang.AssertionError: > Expected: a string containing "Message received: Created entry 'Test Value'" > but: was " > . ____ _ __ _ _ > /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \ > ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \ > \\/ ___)| |_)| | | | | || (_| | ) ) ) ) > ' |____| .__|_| |_|_| |_\__, | / / / / > =========|_|==============|___/=/_/_/_/ > :: Spring Boot :: (v1.4.0.M3) > 2016-06-14 14:34:55.166 INFO 5790 --- [ main] o.j.n.q.spring.QuickstartApplication : Starting QuickstartApplication on jaime.eng.hst.ams2.redhat.com with PID 5790 (/home/hudson/workspace/btny-pulls-narayana-quickstart/spring/narayana-spring-boot/target/classes started by hudson in /home/hudson/workspace/btny-pulls-narayana-quickstart/spring/narayana-spring-boot) > 2016-06-14 14:34:55.167 INFO 5790 --- [ main] o.j.n.q.spring.QuickstartApplication : No active profile set, falling back to default profiles: default > 2016-06-14 14:34:55.170 INFO 5790 --- [ main] s.c.a.AnnotationConfigApplicationContext : Refreshing org.springframework.context.annotation.AnnotationConfigApplicationContext at 1d0cdb6: startup date [Tue Jun 14 14:34:55 BST 2016]; root of context hierarchy > 2016-06-14 14:34:55.655 INFO 5790 --- [ main] f.a.AutowiredAnnotationBeanPostProcessor : JSR-330 'javax.inject.Inject' annotation found and supported for autowiring > 2016-06-14 14:34:55.787 INFO 5790 --- [ main] com.arjuna.ats.jbossatx : ARJUNA032010: JBossTS Recovery Service (tag: unknown) - JBoss Inc. > 2016-06-14 14:34:55.787 INFO 5790 --- [ main] com.arjuna.ats.jbossatx : ARJUNA032013: Starting transaction recovery manager > 2016-06-14 14:34:55.870 INFO 5790 --- [ main] o.s.t.jta.JtaTransactionManager : Using JTA UserTransaction: Transaction: unknown > 2016-06-14 14:34:55.870 INFO 5790 --- [ main] o.s.t.jta.JtaTransactionManager : Using JTA TransactionManager: Transaction: unknown > 2016-06-14 14:34:55.980 INFO 5790 --- [ main] j.LocalContainerEntityManagerFactoryBean : Building JPA container EntityManagerFactory for persistence unit 'default' > 2016-06-14 14:34:55.981 INFO 5790 --- [ main] o.hibernate.jpa.internal.util.LogHelper : HHH000204: Processing PersistenceUnitInfo [ > name: default > ...] > 2016-06-14 14:34:55.995 INFO 5790 --- [ main] org.hibernate.dialect.Dialect : HHH000400: Using dialect: org.hibernate.dialect.H2Dialect > 2016-06-14 14:34:56.040 INFO 5790 --- [ main] o.h.t.schema.internal.SchemaCreatorImpl : HHH000476: Executing import script 'org.hibernate.tool.schema.internal.exec.ScriptSourceInputNonExistentImpl at 637cff' > 2016-06-14 14:34:56.045 INFO 5790 --- [ main] j.LocalContainerEntityManagerFactoryBean : Initialized JPA EntityManagerFactory for persistence unit 'default' > 2016-06-14 14:34:56.191 INFO 5790 --- [ main] org.apache.activemq.artemis.core.server : AMQ221000: live Message Broker is starting with configuration Broker Configuration (clustered=false,journalDirectory=/tmp/artemis-data/journal,bindingsDirectory=data/bindings,largeMessagesDirectory=data/largemessages,pagingDirectory=data/paging) > 2016-06-14 14:34:56.192 INFO 5790 --- [ main] org.apache.activemq.artemis.core.server : AMQ221045: libaio is not available, switching the configuration into NIO > 2016-06-14 14:34:56.193 INFO 5790 --- [ main] org.apache.activemq.artemis.core.server : AMQ221043: Protocol module found: [artemis-server]. Adding protocol support for: CORE > 2016-06-14 14:34:56.220 INFO 5790 --- [ main] org.apache.activemq.artemis.core.server : AMQ221003: Trying to deploy queue jms.queue.quickstart-messages > 2016-06-14 14:34:56.231 INFO 5790 --- [ main] org.apache.activemq.artemis.core.server : AMQ221007: Server is now live > 2016-06-14 14:34:56.231 INFO 5790 --- [ main] org.apache.activemq.artemis.core.server : AMQ221001: Apache ActiveMQ Artemis Message Broker version 1.2.0 [localhost, nodeID=c852656c-3234-11e6-94cb-52540027ba72] > 2016-06-14 14:34:56.496 INFO 5790 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup > 2016-06-14 14:34:56.503 INFO 5790 --- [ main] o.s.c.support.DefaultLifecycleProcessor : Starting beans in phase 2147483647 > 2016-06-14 14:34:56.509 INFO 5790 --- [ main] o.j.n.q.spring.QuickstartApplication : Started QuickstartApplication in 1.418 seconds (JVM running for 10.75) > 2016-06-14 14:34:56.520 INFO 5790 --- [ main] o.h.h.i.QueryTranslatorFactoryInitiator : HHH000397: Using ASTQueryTranslatorFactory > Entries at the start: [] > Creating entry 'Test Value' > Entries at the end: [Entry{id=1, value='Test Value'}] > 2016-06-14 14:34:57.444 INFO 5790 --- [ main] s.c.a.AnnotationConfigApplicationContext : Closing org.springframework.context.annotation.AnnotationConfigApplicationContext at 1d0cdb6: startup date [Tue Jun 14 14:34:55 BST 2016]; root of context hierarchy > 2016-06-14 14:34:57.446 INFO 5790 --- [ main] o.s.c.support.DefaultLifecycleProcessor : Stopping beans in phase 2147483647 > 2016-06-14 14:34:57.447 WARN 5790 --- [enerContainer-1] o.s.j.l.DefaultMessageListenerContainer : Rejecting received message because of the listener container having been stopped in the meantime: ActiveMQMessage[ID:c88ada9c-3234-11e6-94cb-52540027ba72]:PERSISTENT/ClientMessage[messageID=7, durable=true, address=jms.queue.quickstart-messages,userID=c88ada9c-3234-11e6-94cb-52540027ba72,properties=TypedProperties[__AMQ_CID=c8897b08-3234-11e6-94cb-52540027ba72]] > 2016-06-14 14:34:57.456 INFO 5790 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Unregistering JMX-exposed beans on shutdown > 2016-06-14 14:34:57.466 INFO 5790 --- [ main] org.apache.activemq.artemis.core.server : AMQ221002: Apache ActiveMQ Artemis Message Broker version 1.2.0 [c852656c-3234-11e6-94cb-52540027ba72] stopped, uptime 1.275 seconds > 2016-06-14 14:34:57.469 INFO 5790 --- [ main] j.LocalContainerEntityManagerFactoryBean : Closing JPA EntityManagerFactory for persistence unit 'default' > 2016-06-14 14:34:57.470 INFO 5790 --- [ main] .SchemaDropperImpl$DelayedDropActionImpl : HHH000477: Starting delayed drop of schema as part of SessionFactory shut-down' > 2016-06-14 14:34:57.488 INFO 5790 --- [ main] com.arjuna.ats.jbossatx : ARJUNA032014: Stopping transaction recovery manager > " > at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) > at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8) > at org.jboss.narayana.quickstart.spring.QuickstartApplicationTests.testCommit(QuickstartApplicationTests.java:41) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.springframework.boot.test.rule.OutputCapture$1.evaluate(OutputCapture.java:61) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) > at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:06 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2685) Check that narayana builds and runs using the Java SE 9 compiler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2685: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Check that narayana builds and runs using the Java SE 9 compiler > ---------------------------------------------------------------- > > Key: JBTM-2685 > URL: https://issues.jboss.org/browse/JBTM-2685 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Affects Versions: 5.3.3.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > Get the latest build from https://jdk9.java.net/download/ and check for any issues. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:06 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2678) @TxLogged annotation does not work In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2678: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > @TxLogged annotation does not work > ---------------------------------- > > Key: JBTM-2678 > URL: https://issues.jboss.org/browse/JBTM-2678 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Compensations > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Fix For: 5.next > > > @TxLogged annotation does not work in Compensations framework. All it's assertions were removed from the tests with this commit: https://github.com/jbosstm/narayana/commit/efd15eeb080c6b6338f3658c4aa58158c5e3ac6a#diff-a01554d0172e1da7703c5134820edb6aL124 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:06 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2673) ThreadUtil getThreadId(Thread) ignores argument In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2673: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > ThreadUtil getThreadId(Thread) ignores argument > ----------------------------------------------- > > Key: JBTM-2673 > URL: https://issues.jboss.org/browse/JBTM-2673 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > During investigation of https://developer.jboss.org/thread/269784?start=15&tstart=0 it was observed that the ThreadUtil implementation does not use the Thread argument and simply uses a ThreadLocal: > https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/utils/ThreadUtil.java#L51 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:06 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2662) Export org.jboss.tm, has 1, private references [org.jboss.logging] In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2662: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Export org.jboss.tm, has 1, private references [org.jboss.logging] > -------------------------------------------------------------------- > > Key: JBTM-2662 > URL: https://issues.jboss.org/browse/JBTM-2662 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:06 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2661) Unknown directive cardinality: in Require-Capability In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2661: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Unknown directive cardinality: in Require-Capability > ---------------------------------------------------- > > Key: JBTM-2661 > URL: https://issues.jboss.org/browse/JBTM-2661 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > [WARNING] Bundle org.jboss.narayana.osgi:narayana-osgi-jta:bundle:5.3.3.Final-SNAPSHOT : Unknown directive cardinality: in Require-Capability, allowed directives are effective:,resolution:,filter:, and 'x-*'. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:06 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:06 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2659) narayana-osgi-jta build bundle warings In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2659: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > narayana-osgi-jta build bundle warings > -------------------------------------- > > Key: JBTM-2659 > URL: https://issues.jboss.org/browse/JBTM-2659 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > There are three warning when building the bundle. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:07 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2656) XATerminatorImple#recover could return an empty array in preference to null In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2656: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > XATerminatorImple#recover could return an empty array in preference to null > --------------------------------------------------------------------------- > > Key: JBTM-2656 > URL: https://issues.jboss.org/browse/JBTM-2656 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA > Affects Versions: 5.3.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The javadoc (http://docs.oracle.com/javaee/7/api/javax/resource/spi/XATerminator.html#recover-int-) for the XATerminator recover > method says the resource manager should return zero or more XIDs or throw an exception but our implementation of it returns null if there are no in doubt Xids. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:07 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2652) Include STM javadocs on narayana.io In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2652: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Include STM javadocs on narayana.io > ----------------------------------- > > Key: JBTM-2652 > URL: https://issues.jboss.org/browse/JBTM-2652 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation, STM > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Should be part of http://narayana.io/docs/api/index.html -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:07 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2646) Include a quickstart showing a command line equivalent of the wildfly transaction console In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2646: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Include a quickstart showing a command line equivalent of the wildfly transaction console > ----------------------------------------------------------------------------------------- > > Key: JBTM-2646 > URL: https://issues.jboss.org/browse/JBTM-2646 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Tooling > Affects Versions: 5.3.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > Provide a standalone tool (in the form of a quickstart) that duplicates the functionality of the wildfly transactions console. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:07 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2623) Check Glassfish-to-Narayana interoperability (via JTS). In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2623: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Check Glassfish-to-Narayana interoperability (via JTS). > ------------------------------------------------------- > > Key: JBTM-2623 > URL: https://issues.jboss.org/browse/JBTM-2623 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.2.13.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > This task facilitates the resolution of JBTM-223 Check WL-to-JBossTS interoperability (via JTS). > Whilst developing a test for recovery with WebLogic I was unable to make progress due to issue \[1\] (basically registering resources for recovery fails). Checking recovery using glassfish may be easier since the source code is readily available and may help with figuring out the correct solution with WL. > \[1\] According to [https://docs.oracle.com/cd/E12839_01/web.1111/e13731/jtatxexp.htm#WLJTA279] > XA resources can be registered for recovery via a singleton bean that runs at start up and registers them with the WL transaction manager. When I do this I get the exception as shown: > {quote} > javax.transaction.SystemException: Resource 'Dummy'can be registered only in a server process > at org.glassfish.transaction.TransactionManagerImplCommon.registerStaticResource(TransactionManagerImplCommon.java:695) > at org.jboss.narayana.RecoveryBean.register(RecoveryBean.java:61) > at org.jboss.narayana.RecoveryBean.init(RecoveryBean.java:30) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethod(Jsr250Metadata.java:377) > at com.oracle.pitchfork.inject.Jsr250Metadata.invokeLifecycleMethods(Jsr250Metadata.java:352) > at com.oracle.pitchfork.intercept.InterceptionMetadata.invokeLifecycleMethods(InterceptionMetadata.java:399) > at weblogic.ejb.container.injection.EjbComponentCreatorImpl.invokePostConstruct(EjbComponentCreatorImpl.java:55) > at weblogic.ejb.container.manager.SingletonSessionManager.constructAndInitBean(SingletonSessionManager.java:330) > at weblogic.ejb.container.manager.SingletonSessionManager.access$300(SingletonSessionManager.java:62) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.doActualInit(SingletonSessionManager.java:753) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.initInternal(SingletonSessionManager.java:701) > at weblogic.ejb.container.manager.SingletonSessionManager$SingletonLifecycleManager.init(SingletonSessionManager.java:588) > at weblogic.ejb.container.manager.SingletonSessionManager.init(SingletonSessionManager.java:255) > at weblogic.ejb.container.manager.SingletonSessionManager.perhapsInit(SingletonSessionManager.java:251) > at weblogic.ejb.container.deployer.EJBDeployer.start(EJBDeployer.java:968) > at weblogic.ejb.container.deployer.EJBModule.start(EJBModule.java:597) > at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:360) > at weblogic.application.internal.ExtensibleModuleWrapper$StartStateChange.next(ExtensibleModuleWrapper.java:356) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:138) > at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124) > at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:216) > at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:211) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.flow.ModuleStateDriver.start(ModuleStateDriver.java:73) > at weblogic.application.internal.flow.StartModulesFlow.activate(StartModulesFlow.java:24) > at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:729) > at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) > at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:258) > at weblogic.application.internal.SingleModuleDeployment.activate(SingleModuleDeployment.java:48) > at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165) > at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80) > at weblogic.deploy.internal.targetserver.BasicDeployment.activate(BasicDeployment.java:226) > at weblogic.deploy.internal.targetserver.BasicDeployment.activateFromServerLifecycle(BasicDeployment.java:418) > at weblogic.management.deploy.internal.DeploymentAdapter$1.doActivate(DeploymentAdapter.java:51) > at weblogic.management.deploy.internal.DeploymentAdapter.activate(DeploymentAdapter.java:200) > at weblogic.management.deploy.internal.AppTransition$2.transitionApp(AppTransition.java:30) > at weblogic.management.deploy.internal.ConfiguredDeployments.transitionApps(ConfiguredDeployments.java:240) > at weblogic.management.deploy.internal.ConfiguredDeployments.activate(ConfiguredDeployments.java:169) > at weblogic.management.deploy.internal.ConfiguredDeployments.deploy(ConfiguredDeployments.java:123) > at weblogic.management.deploy.internal.DeploymentServerService.resume(DeploymentServerService.java:210) > at weblogic.management.deploy.internal.DeploymentServerService.start(DeploymentServerService.java:118) > at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:78) > at sun.reflect.GeneratedMethodAccessor11.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1017) > at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:388) > at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:430) > at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456) > at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225) > at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82) > at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98) > at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:606) > at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:77) > at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:231) > at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:254) > at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:413) > at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:456) > at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:225) > at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:82) > at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2488) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:98) > at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:87) > at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1162) > at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1147) > at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:548) > at weblogic.work.ExecuteThread.execute(ExecuteThread.java:311) > at weblogic.work.ExecuteThread.run(ExecuteThread.java:263) > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:07 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2571) Enable code coverage for XTS crash recovery tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2571: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Enable code coverage for XTS crash recovery tests > ------------------------------------------------- > > Key: JBTM-2571 > URL: https://issues.jboss.org/browse/JBTM-2571 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: XTS > Reporter: Gytis Trikleris > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > Code coverage data is not collected during the XTS crash recovery tests execution. Currently this seems to be blocked by [1], [2], and [3]. > [1] https://community.jboss.org/message/817252 > [2] https://issues.jboss.org/browse/ARQ-1014 > [3] https://issues.jboss.org/browse/ARQ-918 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:07 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:07 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2553) Investigate the test with byteman do not work with the jacoco In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2553: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > 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 > Priority: Minor > Fix For: 5.next > > -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:03:08 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:03:08 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2498) Incomplete BlackTie quickstart documentation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2498: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Incomplete BlackTie quickstart documentation > -------------------------------------------- > > Key: JBTM-2498 > URL: https://issues.jboss.org/browse/JBTM-2498 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie, Demonstrator, Documentation > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The BlackTie README.md quickstart files are out of date with respect to running against the latest wildfly. > Ideally, the quickstarts should be standalone (and automatable - run.sh nearly works but not quite) so we need better instructions on how to configure, start and deploy to wildfly. > My ideal quickstart is one from which I can cut lines and paste into a terminal in order to get it working. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:04:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2115) Not all classes are under code coverage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2115: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Not all classes are under code coverage > --------------------------------------- > > Key: JBTM-2115 > URL: https://issues.jboss.org/browse/JBTM-2115 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Affects Versions: 5.0.1 > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The following poms contain skipped classes for code coverage: > ArjunaCore/arjuna/pom.xml > ArjunaJTA/jdbc/pom.xml > ArjunaJTA/jta/pom.xml > ArjunaJTA/spi/pom.xml > XTS/localjunit/pom.xml > We should aim to test everything -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:04:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:04:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1804) JTS remote tests not run and no code coverage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1804: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > JTS remote tests not run and no code coverage > --------------------------------------------- > > Key: JBTM-1804 > URL: https://issues.jboss.org/browse/JBTM-1804 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: JTS, Testing > Affects Versions: 5.0.0.M3 > Reporter: Mark Little > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > The tests in .remote. package for JTS are not run by default. We should consider adding a build option so that they are run (will require some mods to the tests since many of them are client/server based - see associated Readme.txt files); don't run them by default since they will add delay to a normal build. > It would then be beneficial to have them instrumented by emma to get code coverage. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:04:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:04:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1107) Recovery Support in Compensation API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1107: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Recovery Support in Compensation API > ------------------------------------ > > Key: JBTM-1107 > URL: https://issues.jboss.org/browse/JBTM-1107 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Compensations > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 5.next > > > *Background* > Currently Compensations API cannot handle system failures. Transaction state is not persisted in any stage. Thus no handlers will be invoked in case of the system crash. > *Requirements* > # Make handlers persistable (CompensationHandler, ConfirmationHandler, TransactionLoggedHandler). > ## Require Serializable interface. > ## Create PersistableHandler interface (similar to PersistableParticipant in RTS integration). > # Make participant persistable (ParticipantImpl, LocalParticipant, RemoteParticipant). > ## Make transaction identifier persistable (converting it to String should work). > ## Implement PersistableParticipant in ParticipantImpl. > ## Investigate if PARTICIPANT_COUNTERS in ParticipatnImpl have to be updated. > # Make compensation scoped beans persistable. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:04:01 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:04:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-223) Check WL-to-JBossTS interoperability (via JTS). In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-223: ------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Check WL-to-JBossTS interoperability (via JTS). > ----------------------------------------------- > > Key: JBTM-223 > URL: https://issues.jboss.org/browse/JBTM-223 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Reporter: Mark Little > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > Extensible header structure corba call > key value slot ids > slot for transaction context is not in the well known slot > tx context was not defined so we used the market leader at the time -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 09:04:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 09:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2334) Improve ease of use within Tomcat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2334: -------------------------------- Fix Version/s: 5.next (was: 5.3.5.Final) > Improve ease of use within Tomcat > --------------------------------- > > Key: JBTM-2334 > URL: https://issues.jboss.org/browse/JBTM-2334 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTA > Reporter: Mark Little > Assignee: Gytis Trikleris > Fix For: 5.next > > > Initial requirements: > # Implement a Narayana Tomcat module which provides an archive with all dependencies necessary for deployment on Tomcat: common, core, jta, jdbc, cdi, spi, jms (optional) > # Implement Tomcat lifecycle listener to bootstrap TM and RM > # Provide custom Narayana configuration file for Tomcat > # Provide context.xml with required configurations: lifecycle listener, UserTransaction, SynchronizationRegistry > # Add pooling to transactional driver (either implement it or use some library) -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 16:10:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 16:10:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2761) Add the nexus repository to the OSGi quickstart In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2761: ----------------------------------- Summary: Add the nexus repository to the OSGi quickstart Key: JBTM-2761 URL: https://issues.jboss.org/browse/JBTM-2761 Project: JBoss Transaction Manager Issue Type: Feature Request Components: Documentation Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next Can't be found by the CI system until it flushes to maven central -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 16:11:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 16:11:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2761) Add the nexus repository to the OSGi quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #178 in GitHub ------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Add the nexus repository to the OSGi quickstart > ----------------------------------------------- > > Key: JBTM-2761 > URL: https://issues.jboss.org/browse/JBTM-2761 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Can't be found by the CI system until it flushes to maven central -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 17:31:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 17:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2762) Specify the branch to push on for performance CI script In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2762: ----------------------------------- Summary: Specify the branch to push on for performance CI script Key: JBTM-2762 URL: https://issues.jboss.org/browse/JBTM-2762 Project: JBoss Transaction Manager Issue Type: Task Components: Build System Reporter: Tom Jenkinson Assignee: Tom Jenkinson fatal: You are pushing to remote 'https://jbosstm-bot**************@github.com/jbosstm/artifacts.git', which is not the upstream of your current branch 'master', without telling me what to push to update which remote branch. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Thu Sep 29 17:33:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 29 Sep 2016 17:33:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2762) Specify the branch to push on for performance CI script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #37 in GitHub ------------------------------------------------------------------------------------------ Status: Pull Request Sent (was: Open) > Specify the branch to push on for performance CI script > ------------------------------------------------------- > > Key: JBTM-2762 > URL: https://issues.jboss.org/browse/JBTM-2762 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Build System > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > > fatal: You are pushing to remote 'https://jbosstm-bot**************@github.com/jbosstm/artifacts.git', which is not the upstream of > your current branch 'master', without telling me what to push > to update which remote branch. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 11:47:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 30 Sep 2016 11:47:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2728) Add a forget operation to the tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2728: -------------------------------- Fix Version/s: 5.3.5.Final (was: 5.next) > Add a forget operation to the tooling > ------------------------------------- > > Key: JBTM-2728 > URL: https://issues.jboss.org/browse/JBTM-2728 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Tooling > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.3.5.Final > > > The tooling provides two features for dealing with heuristic participants: > * a recover command that will move it back into the prepared state if the admin thinks a second prepare attempt is likely to succeed; > * a delete operation if the admin thinks it safe to do so; > > In the case of XA resources we also need a forget operation which will trigger the resource adaptor to clean up its end instead of relying on the admin to use tooling provided by the RA to clean up. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 11:47:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 30 Sep 2016 11:47:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2728) Add a forget operation to the tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2728: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Add a forget operation to the tooling > ------------------------------------- > > Key: JBTM-2728 > URL: https://issues.jboss.org/browse/JBTM-2728 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Tooling > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.3.5.Final > > > The tooling provides two features for dealing with heuristic participants: > * a recover command that will move it back into the prepared state if the admin thinks a second prepare attempt is likely to succeed; > * a delete operation if the admin thinks it safe to do so; > > In the case of XA resources we also need a forget operation which will trigger the resource adaptor to clean up its end instead of relying on the admin to use tooling provided by the RA to clean up. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 11:48:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 30 Sep 2016 11:48:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2752) Database connection on POSTGRE required max_prepared_statement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2752: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Database connection on POSTGRE required max_prepared_statement > -------------------------------------------------------------- > > Key: JBTM-2752 > URL: https://issues.jboss.org/browse/JBTM-2752 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.next > > > max_prepared_statement is required on the file (postgre.conf) to connect on pgsql base. > If this option wasn't activate, the method end is called twice on PGXAConnection > Please find below original discussion : > https://developer.jboss.org/message/958507#958507 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 11:49:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 30 Sep 2016 11:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2752) Database connection on POSTGRE required max_prepared_statement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2752: -------------------------------- Fix Version/s: 5.3.5.Final (was: 5.next) > Database connection on POSTGRE required max_prepared_statement > -------------------------------------------------------------- > > Key: JBTM-2752 > URL: https://issues.jboss.org/browse/JBTM-2752 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.3.5.Final > > > max_prepared_statement is required on the file (postgre.conf) to connect on pgsql base. > If this option wasn't activate, the method end is called twice on PGXAConnection > Please find below original discussion : > https://developer.jboss.org/message/958507#958507 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 11:49:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 30 Sep 2016 11:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2752) Database connection on POSTGRE required max_prepared_statement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2752. ------------------------------- > Database connection on POSTGRE required max_prepared_statement > -------------------------------------------------------------- > > Key: JBTM-2752 > URL: https://issues.jboss.org/browse/JBTM-2752 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.3.5.Final > > > max_prepared_statement is required on the file (postgre.conf) to connect on pgsql base. > If this option wasn't activate, the method end is called twice on PGXAConnection > Please find below original discussion : > https://developer.jboss.org/message/958507#958507 -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 11:49:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 30 Sep 2016 11:49:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2728) Add a forget operation to the tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2728. ------------------------------- > Add a forget operation to the tooling > ------------------------------------- > > Key: JBTM-2728 > URL: https://issues.jboss.org/browse/JBTM-2728 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Tooling > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.3.5.Final > > > The tooling provides two features for dealing with heuristic participants: > * a recover command that will move it back into the prepared state if the admin thinks a second prepare attempt is likely to succeed; > * a delete operation if the admin thinks it safe to do so; > > In the case of XA resources we also need a forget operation which will trigger the resource adaptor to clean up its end instead of relying on the admin to use tooling provided by the RA to clean up. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 11:51:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 30 Sep 2016 11:51:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2749: -------------------------------- Fix Version/s: 5.3.5.Final (was: 5.next) > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.3.5.Final > > > When EJB remoting sees an incoming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 11:51:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 30 Sep 2016 11:51:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2749. ------------------------------- Resolution: Done > Add an SPI method to lookup imported transactions by Xid > -------------------------------------------------------- > > Key: JBTM-2749 > URL: https://issues.jboss.org/browse/JBTM-2749 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JCA, SPI > Affects Versions: 5.3.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.3.5.Final > > > When EJB remoting sees an incoming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 11:53:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 30 Sep 2016 11:53:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2755) Allow btadmin to load servers from 127.0.0.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2755: -------------------------------- Fix Version/s: 5.3.5.Final (was: 5.next) > Allow btadmin to load servers from 127.0.0.1 > -------------------------------------------- > > Key: JBTM-2755 > URL: https://issues.jboss.org/browse/JBTM-2755 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.3.5.Final > > > This means that when we add new nodes we don't have to add to the test each time -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 11:53:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 30 Sep 2016 11:53:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2755) Allow btadmin to load servers from 127.0.0.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2755. ------------------------------- Resolution: Done > Allow btadmin to load servers from 127.0.0.1 > -------------------------------------------- > > Key: JBTM-2755 > URL: https://issues.jboss.org/browse/JBTM-2755 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.3.5.Final > > > This means that when we add new nodes we don't have to add to the test each time -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 11:54:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 30 Sep 2016 11:54:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2498) Incomplete BlackTie quickstart documentation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2498: -------------------------------- Fix Version/s: 5.3.5.Final (was: 5.next) > Incomplete BlackTie quickstart documentation > -------------------------------------------- > > Key: JBTM-2498 > URL: https://issues.jboss.org/browse/JBTM-2498 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie, Demonstrator, Documentation > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Minor > Fix For: 5.3.5.Final > > > The BlackTie README.md quickstart files are out of date with respect to running against the latest wildfly. > Ideally, the quickstarts should be standalone (and automatable - run.sh nearly works but not quite) so we need better instructions on how to configure, start and deploy to wildfly. > My ideal quickstart is one from which I can cut lines and paste into a terminal in order to get it working. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 11:54:00 2016 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 30 Sep 2016 11:54:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2498) Incomplete BlackTie quickstart documentation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2498. ------------------------------- Resolution: Done > Incomplete BlackTie quickstart documentation > -------------------------------------------- > > Key: JBTM-2498 > URL: https://issues.jboss.org/browse/JBTM-2498 > Project: JBoss Transaction Manager > Issue Type: Task > Components: BlackTie, Demonstrator, Documentation > Affects Versions: 5.2.2 > Reporter: Michael Musgrove > Assignee: Amos Feng > Priority: Minor > Fix For: 5.3.5.Final > > > The BlackTie README.md quickstart files are out of date with respect to running against the latest wildfly. > Ideally, the quickstarts should be standalone (and automatable - run.sh nearly works but not quite) so we need better instructions on how to configure, start and deploy to wildfly. > My ideal quickstart is one from which I can cut lines and paste into a terminal in order to get it working. -- This message was sent by Atlassian JIRA (v6.4.11#64026) From issues at jboss.org Fri Sep 30 17:13:00 2016 From: issues at jboss.org (davidkarlsen (JIRA)) Date: Fri, 30 Sep 2016 17:13:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2763) problem running with hibernate In-Reply-To: References: Message-ID: davidkarlsen created JBTM-2763: ---------------------------------- Summary: problem running with hibernate Key: JBTM-2763 URL: https://issues.jboss.org/browse/JBTM-2763 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Affects Versions: 5.3.5.Final Environment: Spring 4.3.3.RELEASE Hibernate 5.1.2.Final Narayana 5.3.5 Not in an application server - running standalone spring app Reporter: davidkarlsen With the same libraries as above, except narayana 5.3.5 the following config worked just fine: {noformat} org.hibernate.cache.ehcache.SingletonEhCacheRegionFactory ${hibernate.cache.use_query_cache} ${hibernate.cache.use_second_level_cache} ${hibernate.generate_statistics} ${hibernate.cache.use_structured_entries} ${hibernate.transaction.jta.platform:org.hibernate.engine.transaction.jta.platform.internal.JBossStandAloneJtaPlatform} ${hibernate.connection.release_mode:AFTER_STATEMENT} ${hibernate.jdbc.use_get_generated_keys} ${hibernate.jdbc.fetch_size} ${hibernate.jdbc.batch_size} ${hibernate.showSql} ${hibernate.format_sql} ${hibernate.use_sql_comments} {noformat} If I upgrade Narayana to 5.3.5 I consistently get: {noformat} java.sql.SQLSyntaxErrorException: ORA-02049: timeout: distributed transaction waiting for lock at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:450) at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:399) at oracle.jdbc.driver.T4C8Oall.processError(T4C8Oall.java:1059) at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:522) at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:257) at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:587) at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:210) at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:30) at oracle.jdbc.driver.T4CStatement.executeForRows(T4CStatement.java:931) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1150) at oracle.jdbc.driver.OracleStatement.executeInternal(OracleStatement.java:1792) at oracle.jdbc.driver.OracleStatement.execute(OracleStatement.java:1745) at oracle.jdbc.driver.OracleStatementWrapper.execute(OracleStatementWrapper.java:334) at sun.reflect.GeneratedMethodAccessor84.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at net.bull.javamelody.JdbcWrapper.doExecute(JdbcWrapper.java:404) at net.bull.javamelody.JdbcWrapper$StatementInvocationHandler.invoke(JdbcWrapper.java:129) at net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler.invoke(JdbcWrapper.java:286) at com.sun.proxy.$Proxy143.execute(Unknown Source) at org.dbunit.database.statement.SimpleStatement.executeBatch(SimpleStatement.java:69) at org.dbunit.operation.DeleteAllOperation.execute(DeleteAllOperation.java:126) at org.dbunit.operation.CompositeOperation.execute(CompositeOperation.java:79) at com.github.springtestdbunit.DbUnitRunner.setupOrTeardown(DbUnitRunner.java:183) at com.github.springtestdbunit.DbUnitRunner.beforeTestMethod(DbUnitRunner.java:75) at com.github.springtestdbunit.DbUnitTestExecutionListener.beforeTestMethod(DbUnitTestExecutionListener.java:185) at org.springframework.test.context.TestContextManager.beforeTestMethod(TestContextManager.java:269) at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:86) at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) at org.junit.rules.RunRules.evaluate(RunRules.java:20) at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:84) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:252) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:94) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61) at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:191) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter. {noformat} If I leave hibernate.connection.release_mode to default (e.g. not specifying it) or after_transaction I get: {noformat} WARN com.arjuna.ats.jta - ARJUNA016029: SynchronizationImple.afterCompletion - failed for org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization at 6811fa19 with exception 22:59:01 java.lang.NullPointerException: null 22:59:01 at com.arjuna.ats.internal.jdbc.ConnectionImple.getConnection(ConnectionImple.java:864) 22:59:01 at com.arjuna.ats.internal.jdbc.ConnectionImple.getWarnings(ConnectionImple.java:476) 22:59:01 at sun.reflect.GeneratedMethodAccessor113.invoke(Unknown Source) 22:59:01 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 22:59:01 at java.lang.reflect.Method.invoke(Method.java:498) 22:59:01 at net.bull.javamelody.JdbcWrapper$ConnectionInvocationHandler.invoke(JdbcWrapper.java:189) 22:59:01 at net.bull.javamelody.JdbcWrapper$DelegatingInvocationHandler.invoke(JdbcWrapper.java:286) 22:59:01 at com.sun.proxy.$Proxy116.getWarnings(Unknown Source) 22:59:01 at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.handleAndClearWarnings(SqlExceptionHelper.java:277) 22:59:01 at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.logAndClearWarnings(SqlExceptionHelper.java:256) 22:59:01 at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.releaseConnection(LogicalConnectionManagedImpl.java:167) 22:59:01 at org.hibernate.resource.jdbc.internal.LogicalConnectionManagedImpl.afterTransaction(LogicalConnectionManagedImpl.java:135) 22:59:01 at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransaction(JdbcCoordinatorImpl.java:296) 22:59:01 at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.afterTransactionCompletion(JdbcCoordinatorImpl.java:496) 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.afterCompletion(JtaTransactionCoordinatorImpl.java:345) 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.doAfterCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:60) 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorTrackingImpl.afterCompletion(SynchronizationCallbackCoordinatorTrackingImpl.java:72) 22:59:01 at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.afterCompletion(RegisteredSynchronization.java:44) 22:59:01 at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.afterCompletion(SynchronizationImple.java:96) 22:59:01 at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.afterCompletion(TwoPhaseCoordinator.java:542) 22:59:01 at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:101) 22:59:01 at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) 22:59:01 at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1216) 22:59:01 at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) 22:59:01 at org.springframework.transaction.jta.JtaTransactionManager.doCommit(JtaTransactionManager.java:1023) 22:59:01 at org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:761) 22:59:01 at org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:730) 22:59:01 at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:487) 22:59:01 at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:291) 22:59:01 at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96) 22:59:01 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) 22:59:01 at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92) 22:59:01 at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) 22:59:01 at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:213) 22:59:01 at com.sun.proxy.$Proxy292.create(Unknown Source) 22:59:01 at {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)