From issues at jboss.org Mon Jun 4 06:58:01 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 4 Jun 2018 06:58:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3028) LRA tests can fail if the network is running slowly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3028: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > LRA tests can fail if the network is running slowly > --------------------------------------------------- > > Key: JBTM-3028 > URL: https://issues.jboss.org/browse/JBTM-3028 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > SpecIT#acceptTest failed on CI (http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/PROFILE=MAIN,jdk=jdk8.latest,label=linux/187/) and on one of the PRs. > [~ochaloup] did some investigation: > {quote} > I did some experiments with the lra testing and normally tests pass on my laptop. But as you mentioned it's probably timing issue as when I slow down the network (I used tc as described at [1]) then the tests started to fail[2] (I'm on master branch). > Do you think you can check it on your laptop if you can see the same issue? Or how to manage that? > Thanks > o. > [1] https://jvns.ca/blog/2017/04/01/slow-down-your-internet-with-tc/ > [2] > Tests run: 23, Failures: 3, Errors: 0, Skipped: 0, Time elapsed: 489.336 sec <<< FAILURE! - in io.narayana.lra.participant.SpecIT > timeLimitRequiredLRA(io.narayana.lra.participant.SpecIT) Time elapsed: 14.474 sec <<< FAILURE! > java.lang.AssertionError: timeLimitRequiredLRA: compensate should have been called expected:<1> but was:<0> > at io.narayana.lra.participant.SpecIT.timeLimitRequiredLRA(SpecIT.java:535) > acceptTest(io.narayana.lra.participant.SpecIT) Time elapsed: 30.335 sec <<< FAILURE! > java.lang.AssertionError: expected:<0> but was:<2> > at io.narayana.lra.participant.SpecIT.joinAndEnd(SpecIT.java:649) > at io.narayana.lra.participant.SpecIT.acceptTest(SpecIT.java:624) > connectionHangup(io.narayana.lra.participant.SpecIT) Time elapsed: 35.179 sec <<< FAILURE! > java.lang.AssertionError: connectionHangup: wrong compensation count after recovery expected:<7> but was:<6> > at io.narayana.lra.participant.SpecIT.connectionHangup(SpecIT.java:266) > {quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 4 12:45:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 4 Jun 2018 12:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3029) SpecIT.timeLimitRequiredLRA failed on Windows CI In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-3029: -------------------------------------- Summary: SpecIT.timeLimitRequiredLRA failed on Windows CI Key: JBTM-3029 URL: https://issues.jboss.org/browse/JBTM-3029 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA, Testing Affects Versions: 5.8.2.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next Failed on CI run http://172.17.130.4:8083/job/narayana-mac/PROFILE=MAIN,jdk=jdk8.latest,label=mac/423/console The test does a timed wait on a condition which eventually times out. The test may just need tweaking or alternatively a more sophisticated test may be required. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 5 21:10:00 2018 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 5 Jun 2018 21:10:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3030) Moving the tomcat-jta to the JWS web-servers repo In-Reply-To: References: Message-ID: Amos Feng created JBTM-3030: ------------------------------- Summary: Moving the tomcat-jta to the JWS web-servers repo Key: JBTM-3030 URL: https://issues.jboss.org/browse/JBTM-3030 Project: JBoss Transaction Manager Issue Type: Task Reporter: Amos Feng Assignee: Amos Feng -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 5 21:10:00 2018 From: issues at jboss.org (Amos Feng (JIRA)) Date: Tue, 5 Jun 2018 21:10:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3030) Moving the tomcat-jta to the JWS web-servers repo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng updated JBTM-3030: ---------------------------- Component/s: Tomcat > Moving the tomcat-jta to the JWS web-servers repo > ------------------------------------------------- > > Key: JBTM-3030 > URL: https://issues.jboss.org/browse/JBTM-3030 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Tomcat > Reporter: Amos Feng > Assignee: Amos Feng > -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jun 8 04:18:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 8 Jun 2018 04:18:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3029) SpecIT.timeLimitRequiredLRA failed on Mac CI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3029: ----------------------------------- Summary: SpecIT.timeLimitRequiredLRA failed on Mac CI (was: SpecIT.timeLimitRequiredLRA failed on Windows CI) > SpecIT.timeLimitRequiredLRA failed on Mac CI > -------------------------------------------- > > Key: JBTM-3029 > URL: https://issues.jboss.org/browse/JBTM-3029 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA, Testing > Affects Versions: 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Failed on CI run http://172.17.130.4:8083/job/narayana-mac/PROFILE=MAIN,jdk=jdk8.latest,label=mac/423/console > The test does a timed wait on a condition which eventually times out. The test may just need tweaking or alternatively a more sophisticated test may be required. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jun 8 05:42:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 8 Jun 2018 05:42:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3031) Error messages for XTS registration is unprecise and hardly tracable In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-3031: ------------------------------------- Summary: Error messages for XTS registration is unprecise and hardly tracable Key: JBTM-3031 URL: https://issues.jboss.org/browse/JBTM-3031 Project: JBoss Transaction Manager Issue Type: Bug Components: XTS Affects Versions: 5.8.2.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Based on the changes made for JBTM-2928 : Provide WS-AT Integration with .NET we discussed with [~f_marchioni] there are gaps in understandability of error messages and it's hard to be traced. The point is to report the XTS WS-AT register errors in better way. Here is some of the points {quote} Francesco Marchioni: In the test testAlreadyRegisteredProtocolIdentifierException Francesco Marchioni: ?? ??????http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register<...> ??????testAlreadyRegisteredProtocolIdentifierException ??????http://localhost:8080/ws-c11/RegistrationService ?????? ????????
http://localhost:8080/ws-c11/RegistrationResponseService
??????
?????? ????????
http://localhost:8080/ws-c11/CoordinationFaultService
??????
??????identifier ??
?? ?????? ???????? http://wsc.example.org/already-registered-protocol-identifier ???????? ????????????http://wsc.example.org/protocol-participant-service ???????????? ?????????????? participant ???????????? ???????????? ?????????????? wsc:ProtocolParticipantService ???????????? ???????? ?????? ??
?? ??????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault ??????urn:uuid:e4953fa1-0dc2-41cb-a565-0f446fa0e86c ??????http://localhost:8080/ws-c11/CoordinationFaultService ??????testAlreadyRegisteredProtocolIdentifierException ?? ?? ?????? ???????? wscoor:CannotRegister ???????? Sender ???????? ????????????ARJUNA042081: Participant already registered ???????? ?????? ?? Francesco Marchioni: The Exception message seem not correct: It's "Participant already registered" {quote} {quote} Francesco Marchioni: RegistrationServiceTest there's one similar Francesco Marchioni: ????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault ????urn:uuid:ff6387eb-df3a-4e97-9349-d39c042ac584 ????http://localhost:8080/ws-c11/CoordinationFaultService ????testUnknownCoordinationType ?? ?? ???? ??????wscoor:InvalidProtocol ??????Sender ?????? ????????ARJUNA042082: Invalid protocol identifier ?????? ???? ?? Francesco Marchioni: It says "invalid protocol identifier" for a test of unknownCoordinationType {quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jun 8 05:42:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 8 Jun 2018 05:42:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3031) Error messages for XTS registration is unprecise and hardly tracable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3031: ---------------------------------- Description: Based on the changes made for JBTM-2928 : Provide WS-AT Integration with .NET we discussed with [~f_marchioni] there are gaps in understandability of error messages and it's hard to be traced. The point is to report the XTS WS-AT register errors in better way. Here is some of the points {code} Francesco Marchioni: In the test testAlreadyRegisteredProtocolIdentifierException Francesco Marchioni: ?? ??????http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register<...> ??????testAlreadyRegisteredProtocolIdentifierException ??????http://localhost:8080/ws-c11/RegistrationService ?????? ????????
http://localhost:8080/ws-c11/RegistrationResponseService
??????
?????? ????????
http://localhost:8080/ws-c11/CoordinationFaultService
??????
??????identifier ??
?? ?????? ???????? http://wsc.example.org/already-registered-protocol-identifier ???????? ????????????http://wsc.example.org/protocol-participant-service ???????????? ?????????????? participant ???????????? ???????????? ?????????????? wsc:ProtocolParticipantService ???????????? ???????? ?????? ??
?? ??????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault ??????urn:uuid:e4953fa1-0dc2-41cb-a565-0f446fa0e86c ??????http://localhost:8080/ws-c11/CoordinationFaultService ??????testAlreadyRegisteredProtocolIdentifierException ?? ?? ?????? ???????? wscoor:CannotRegister ???????? Sender ???????? ????????????ARJUNA042081: Participant already registered ???????? ?????? ?? Francesco Marchioni: The Exception message seem not correct: It's "Participant already registered" {code} {code} Francesco Marchioni: RegistrationServiceTest there's one similar Francesco Marchioni: ????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault ????urn:uuid:ff6387eb-df3a-4e97-9349-d39c042ac584 ????http://localhost:8080/ws-c11/CoordinationFaultService ????testUnknownCoordinationType ?? ?? ???? ??????wscoor:InvalidProtocol ??????Sender ?????? ????????ARJUNA042082: Invalid protocol identifier ?????? ???? ?? Francesco Marchioni: It says "invalid protocol identifier" for a test of unknownCoordinationType {code} was: Based on the changes made for JBTM-2928 : Provide WS-AT Integration with .NET we discussed with [~f_marchioni] there are gaps in understandability of error messages and it's hard to be traced. The point is to report the XTS WS-AT register errors in better way. Here is some of the points {quote} Francesco Marchioni: In the test testAlreadyRegisteredProtocolIdentifierException Francesco Marchioni: ?? ??????http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register<...> ??????testAlreadyRegisteredProtocolIdentifierException ??????http://localhost:8080/ws-c11/RegistrationService ?????? ????????
http://localhost:8080/ws-c11/RegistrationResponseService
??????
?????? ????????
http://localhost:8080/ws-c11/CoordinationFaultService
??????
??????identifier ??
?? ?????? ???????? http://wsc.example.org/already-registered-protocol-identifier ???????? ????????????http://wsc.example.org/protocol-participant-service ???????????? ?????????????? participant ???????????? ???????????? ?????????????? wsc:ProtocolParticipantService ???????????? ???????? ?????? ??
?? ??????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault ??????urn:uuid:e4953fa1-0dc2-41cb-a565-0f446fa0e86c ??????http://localhost:8080/ws-c11/CoordinationFaultService ??????testAlreadyRegisteredProtocolIdentifierException ?? ?? ?????? ???????? wscoor:CannotRegister ???????? Sender ???????? ????????????ARJUNA042081: Participant already registered ???????? ?????? ?? Francesco Marchioni: The Exception message seem not correct: It's "Participant already registered" {quote} {quote} Francesco Marchioni: RegistrationServiceTest there's one similar Francesco Marchioni: ????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault ????urn:uuid:ff6387eb-df3a-4e97-9349-d39c042ac584 ????http://localhost:8080/ws-c11/CoordinationFaultService ????testUnknownCoordinationType ?? ?? ???? ??????wscoor:InvalidProtocol ??????Sender ?????? ????????ARJUNA042082: Invalid protocol identifier ?????? ???? ?? Francesco Marchioni: It says "invalid protocol identifier" for a test of unknownCoordinationType {quote} > Error messages for XTS registration is unprecise and hardly tracable > -------------------------------------------------------------------- > > Key: JBTM-3031 > URL: https://issues.jboss.org/browse/JBTM-3031 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.8.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > Based on the changes made for JBTM-2928 : Provide WS-AT Integration with .NET we discussed with [~f_marchioni] there are gaps in understandability of error messages and it's hard to be traced. > The point is to report the XTS WS-AT register errors in better way. > Here is some of the points > {code} > Francesco Marchioni: In the test testAlreadyRegisteredProtocolIdentifierException > Francesco Marchioni: > ?? > ??????http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register<...> > ??????testAlreadyRegisteredProtocolIdentifierException > ??????http://localhost:8080/ws-c11/RegistrationService > ?????? > ????????
http://localhost:8080/ws-c11/RegistrationResponseService
> ??????
> ?????? > ????????
http://localhost:8080/ws-c11/CoordinationFaultService
> ??????
> ??????identifier > ??
> ?? > ?????? > ???????? http://wsc.example.org/already-registered-protocol-identifier > ???????? > ????????????http://wsc.example.org/protocol-participant-service > ???????????? > ?????????????? participant > ???????????? > ???????????? > ?????????????? wsc:ProtocolParticipantService > ???????????? > ???????? > ?????? > ?? >
> ?? > ??????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault > ??????urn:uuid:e4953fa1-0dc2-41cb-a565-0f446fa0e86c > ??????http://localhost:8080/ws-c11/CoordinationFaultService > ??????testAlreadyRegisteredProtocolIdentifierException > ?? > ?? > ?????? > ???????? wscoor:CannotRegister > ???????? Sender > ???????? > ????????????ARJUNA042081: Participant already registered > ???????? > ?????? > ?? > > Francesco Marchioni: The Exception message seem not correct: It's "Participant already registered" > {code} > {code} > Francesco Marchioni: RegistrationServiceTest there's one similar > Francesco Marchioni: > ????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault > ????urn:uuid:ff6387eb-df3a-4e97-9349-d39c042ac584 > ????http://localhost:8080/ws-c11/CoordinationFaultService > ????testUnknownCoordinationType > ?? > ?? > ???? > ??????wscoor:InvalidProtocol > ??????Sender > ?????? > ????????ARJUNA042082: Invalid protocol identifier > ?????? > ???? > ?? > > Francesco Marchioni: It says "invalid protocol identifier" for a test of unknownCoordinationType > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jun 8 07:04:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 8 Jun 2018 07:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3031) Error messages for XTS registration is unprecise and hardly tracable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3031: ---------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/1333 > Error messages for XTS registration is unprecise and hardly tracable > -------------------------------------------------------------------- > > Key: JBTM-3031 > URL: https://issues.jboss.org/browse/JBTM-3031 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.8.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > Based on the changes made for JBTM-2928 : Provide WS-AT Integration with .NET we discussed with [~f_marchioni] there are gaps in understandability of error messages and it's hard to be traced. > The point is to report the XTS WS-AT register errors in better way. > Here is some of the points > {code} > Francesco Marchioni: In the test testAlreadyRegisteredProtocolIdentifierException > Francesco Marchioni: > ?? > ??????http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register<...> > ??????testAlreadyRegisteredProtocolIdentifierException > ??????http://localhost:8080/ws-c11/RegistrationService > ?????? > ????????
http://localhost:8080/ws-c11/RegistrationResponseService
> ??????
> ?????? > ????????
http://localhost:8080/ws-c11/CoordinationFaultService
> ??????
> ??????identifier > ??
> ?? > ?????? > ???????? http://wsc.example.org/already-registered-protocol-identifier > ???????? > ????????????http://wsc.example.org/protocol-participant-service > ???????????? > ?????????????? participant > ???????????? > ???????????? > ?????????????? wsc:ProtocolParticipantService > ???????????? > ???????? > ?????? > ?? >
> ?? > ??????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault > ??????urn:uuid:e4953fa1-0dc2-41cb-a565-0f446fa0e86c > ??????http://localhost:8080/ws-c11/CoordinationFaultService > ??????testAlreadyRegisteredProtocolIdentifierException > ?? > ?? > ?????? > ???????? wscoor:CannotRegister > ???????? Sender > ???????? > ????????????ARJUNA042081: Participant already registered > ???????? > ?????? > ?? > > Francesco Marchioni: The Exception message seem not correct: It's "Participant already registered" > {code} > {code} > Francesco Marchioni: RegistrationServiceTest there's one similar > Francesco Marchioni: > ????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault > ????urn:uuid:ff6387eb-df3a-4e97-9349-d39c042ac584 > ????http://localhost:8080/ws-c11/CoordinationFaultService > ????testUnknownCoordinationType > ?? > ?? > ???? > ??????wscoor:InvalidProtocol > ??????Sender > ?????? > ????????ARJUNA042082: Invalid protocol identifier > ?????? > ???? > ?? > > Francesco Marchioni: It says "invalid protocol identifier" for a test of unknownCoordinationType > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jun 8 09:35:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 8 Jun 2018 09:35:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2982) LRA participant completion calls during recovery do not timeout In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2982: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1332 > LRA participant completion calls during recovery do not timeout > --------------------------------------------------------------- > > Key: JBTM-2982 > URL: https://issues.jboss.org/browse/JBTM-2982 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > Participants that do not respond to completion/compensation requests in timely fashion can delay the caller indefinitely. This applies to periodic recovery attempts to contact participants (and to participant calls as a result of LRA close/cancel requests). > The issue also blocks the ability to shutdown the server. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jun 8 10:08:00 2018 From: issues at jboss.org (Francesco Marchioni (JIRA)) Date: Fri, 8 Jun 2018 10:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3031) Error messages for XTS registration is unprecise and hardly tracable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Marchioni updated JBTM-3031: -------------------------------------- Tester: Francesco Marchioni > Error messages for XTS registration is unprecise and hardly tracable > -------------------------------------------------------------------- > > Key: JBTM-3031 > URL: https://issues.jboss.org/browse/JBTM-3031 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.8.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > Based on the changes made for JBTM-2928 : Provide WS-AT Integration with .NET we discussed with [~f_marchioni] there are gaps in understandability of error messages and it's hard to be traced. > The point is to report the XTS WS-AT register errors in better way. > Here is some of the points > {code} > Francesco Marchioni: In the test testAlreadyRegisteredProtocolIdentifierException > Francesco Marchioni: > ?? > ??????http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register<...> > ??????testAlreadyRegisteredProtocolIdentifierException > ??????http://localhost:8080/ws-c11/RegistrationService > ?????? > ????????
http://localhost:8080/ws-c11/RegistrationResponseService
> ??????
> ?????? > ????????
http://localhost:8080/ws-c11/CoordinationFaultService
> ??????
> ??????identifier > ??
> ?? > ?????? > ???????? http://wsc.example.org/already-registered-protocol-identifier > ???????? > ????????????http://wsc.example.org/protocol-participant-service > ???????????? > ?????????????? participant > ???????????? > ???????????? > ?????????????? wsc:ProtocolParticipantService > ???????????? > ???????? > ?????? > ?? >
> ?? > ??????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault > ??????urn:uuid:e4953fa1-0dc2-41cb-a565-0f446fa0e86c > ??????http://localhost:8080/ws-c11/CoordinationFaultService > ??????testAlreadyRegisteredProtocolIdentifierException > ?? > ?? > ?????? > ???????? wscoor:CannotRegister > ???????? Sender > ???????? > ????????????ARJUNA042081: Participant already registered > ???????? > ?????? > ?? > > Francesco Marchioni: The Exception message seem not correct: It's "Participant already registered" > {code} > {code} > Francesco Marchioni: RegistrationServiceTest there's one similar > Francesco Marchioni: > ????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault > ????urn:uuid:ff6387eb-df3a-4e97-9349-d39c042ac584 > ????http://localhost:8080/ws-c11/CoordinationFaultService > ????testUnknownCoordinationType > ?? > ?? > ???? > ??????wscoor:InvalidProtocol > ??????Sender > ?????? > ????????ARJUNA042082: Invalid protocol identifier > ?????? > ???? > ?? > > Francesco Marchioni: It says "invalid protocol identifier" for a test of unknownCoordinationType > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jun 8 10:14:01 2018 From: issues at jboss.org (Francesco Marchioni (JIRA)) Date: Fri, 8 Jun 2018 10:14:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3031) Error messages for XTS registration is unprecise and hardly tracable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588738#comment-13588738 ] Francesco Marchioni commented on JBTM-3031: ------------------------------------------- [~ochaloup] I've verified the PR using the same test suite as https://issues.jboss.org/browse/EAP7-911. The error message now correctly addresses the issue. > Error messages for XTS registration is unprecise and hardly tracable > -------------------------------------------------------------------- > > Key: JBTM-3031 > URL: https://issues.jboss.org/browse/JBTM-3031 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.8.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > Based on the changes made for JBTM-2928 : Provide WS-AT Integration with .NET we discussed with [~f_marchioni] there are gaps in understandability of error messages and it's hard to be traced. > The point is to report the XTS WS-AT register errors in better way. > Here is some of the points > {code} > Francesco Marchioni: In the test testAlreadyRegisteredProtocolIdentifierException > Francesco Marchioni: > ?? > ??????http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register<...> > ??????testAlreadyRegisteredProtocolIdentifierException > ??????http://localhost:8080/ws-c11/RegistrationService > ?????? > ????????
http://localhost:8080/ws-c11/RegistrationResponseService
> ??????
> ?????? > ????????
http://localhost:8080/ws-c11/CoordinationFaultService
> ??????
> ??????identifier > ??
> ?? > ?????? > ???????? http://wsc.example.org/already-registered-protocol-identifier > ???????? > ????????????http://wsc.example.org/protocol-participant-service > ???????????? > ?????????????? participant > ???????????? > ???????????? > ?????????????? wsc:ProtocolParticipantService > ???????????? > ???????? > ?????? > ?? >
> ?? > ??????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault > ??????urn:uuid:e4953fa1-0dc2-41cb-a565-0f446fa0e86c > ??????http://localhost:8080/ws-c11/CoordinationFaultService > ??????testAlreadyRegisteredProtocolIdentifierException > ?? > ?? > ?????? > ???????? wscoor:CannotRegister > ???????? Sender > ???????? > ????????????ARJUNA042081: Participant already registered > ???????? > ?????? > ?? > > Francesco Marchioni: The Exception message seem not correct: It's "Participant already registered" > {code} > {code} > Francesco Marchioni: RegistrationServiceTest there's one similar > Francesco Marchioni: > ????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault > ????urn:uuid:ff6387eb-df3a-4e97-9349-d39c042ac584 > ????http://localhost:8080/ws-c11/CoordinationFaultService > ????testUnknownCoordinationType > ?? > ?? > ???? > ??????wscoor:InvalidProtocol > ??????Sender > ?????? > ????????ARJUNA042082: Invalid protocol identifier > ?????? > ???? > ?? > > Francesco Marchioni: It says "invalid protocol identifier" for a test of unknownCoordinationType > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jun 8 10:21:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 8 Jun 2018 10:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3031) Error messages for XTS registration is unprecise and hardly tracable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588743#comment-13588743 ] Ondra Chaloupka commented on JBTM-3031: --------------------------------------- [~f_marchioni] thank you for checking this out. I really appreciate it. > Error messages for XTS registration is unprecise and hardly tracable > -------------------------------------------------------------------- > > Key: JBTM-3031 > URL: https://issues.jboss.org/browse/JBTM-3031 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.8.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > Based on the changes made for JBTM-2928 : Provide WS-AT Integration with .NET we discussed with [~f_marchioni] there are gaps in understandability of error messages and it's hard to be traced. > The point is to report the XTS WS-AT register errors in better way. > Here is some of the points > {code} > Francesco Marchioni: In the test testAlreadyRegisteredProtocolIdentifierException > Francesco Marchioni: > ?? > ??????http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register<...> > ??????testAlreadyRegisteredProtocolIdentifierException > ??????http://localhost:8080/ws-c11/RegistrationService > ?????? > ????????
http://localhost:8080/ws-c11/RegistrationResponseService
> ??????
> ?????? > ????????
http://localhost:8080/ws-c11/CoordinationFaultService
> ??????
> ??????identifier > ??
> ?? > ?????? > ???????? http://wsc.example.org/already-registered-protocol-identifier > ???????? > ????????????http://wsc.example.org/protocol-participant-service > ???????????? > ?????????????? participant > ???????????? > ???????????? > ?????????????? wsc:ProtocolParticipantService > ???????????? > ???????? > ?????? > ?? >
> ?? > ??????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault > ??????urn:uuid:e4953fa1-0dc2-41cb-a565-0f446fa0e86c > ??????http://localhost:8080/ws-c11/CoordinationFaultService > ??????testAlreadyRegisteredProtocolIdentifierException > ?? > ?? > ?????? > ???????? wscoor:CannotRegister > ???????? Sender > ???????? > ????????????ARJUNA042081: Participant already registered > ???????? > ?????? > ?? > > Francesco Marchioni: The Exception message seem not correct: It's "Participant already registered" > {code} > {code} > Francesco Marchioni: RegistrationServiceTest there's one similar > Francesco Marchioni: > ????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault > ????urn:uuid:ff6387eb-df3a-4e97-9349-d39c042ac584 > ????http://localhost:8080/ws-c11/CoordinationFaultService > ????testUnknownCoordinationType > ?? > ?? > ???? > ??????wscoor:InvalidProtocol > ??????Sender > ?????? > ????????ARJUNA042082: Invalid protocol identifier > ?????? > ???? > ?? > > Francesco Marchioni: It says "invalid protocol identifier" for a test of unknownCoordinationType > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Jun 10 06:03:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sun, 10 Jun 2018 06:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2982) LRA participant completion calls during recovery do not timeout In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2982: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > LRA participant completion calls during recovery do not timeout > --------------------------------------------------------------- > > Key: JBTM-2982 > URL: https://issues.jboss.org/browse/JBTM-2982 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > Participants that do not respond to completion/compensation requests in timely fashion can delay the caller indefinitely. This applies to periodic recovery attempts to contact participants (and to participant calls as a result of LRA close/cancel requests). > The issue also blocks the ability to shutdown the server. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Jun 10 06:06:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sun, 10 Jun 2018 06:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2965) Unused source directory in the quickstart repository In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2965: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Unused source directory in the quickstart repository > ---------------------------------------------------- > > Key: JBTM-2965 > URL: https://issues.jboss.org/browse/JBTM-2965 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > There is an artifact in our quickstart repo that does not look like a quickstart and no other pom in the quickstart and performance repositories references the artifact: > https://github.com/jbosstm/quickstart/tree/master/ArjunaJTS/jta > It has never changed since the initial commit: > {quote} > commit caabc37803bac12e47f4986baca21f9052e14abc > Author: Tom Jenkinson > Date: Tue Oct 2 11:05:51 2012 +0100 > Initial version of a performance comparitor for jts and jta > {quote} > This artefact needs deleting. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Jun 10 06:06:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sun, 10 Jun 2018 06:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2966) narayana-quickstarts-jts quickstart does not run standalone In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2966: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > narayana-quickstarts-jts quickstart does not run standalone > ----------------------------------------------------------- > > Key: JBTM-2966 > URL: https://issues.jboss.org/browse/JBTM-2966 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The recovery quickstart does not run due to missing maven jboss-transaction-spi dependency. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Jun 10 06:07:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sun, 10 Jun 2018 06:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2621) Tests that rely on the old perf benchmark harness need porting to use JMH In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2621: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Tests that rely on the old perf benchmark harness need porting to use JMH > ------------------------------------------------------------------------- > > Key: JBTM-2621 > URL: https://issues.jboss.org/browse/JBTM-2621 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Performance Testing > Affects Versions: 5.2.13.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > The relevant tests are: > com.hp.mwtests.ts.jts.orbspecific.local.performance.Performance1 > com.hp.mwtests.ts.jts.orbspecific.local.performance.Performance2 > com.hp.mwtests.ts.jts.orbspecific.local.performance.Performance3 > if there are no others then once ported the old performance benchmark harness can be removed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Jun 10 06:08:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sun, 10 Jun 2018 06:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2988) Update activemq-artemis in the performance repo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2988: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Update activemq-artemis in the performance repo > ----------------------------------------------- > > Key: JBTM-2988 > URL: https://issues.jboss.org/browse/JBTM-2988 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.7.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > Make sure that the artemis dependency in the performance repo matches what we use on master. So we are currently on 1.5.5.jbossorg-008 so change in the pom in our performance repo to use this version. > Important: make sure that we also *replace* the native AIO library which is located in ArjunaJTA/jta/etc -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Jun 10 06:15:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sun, 10 Jun 2018 06:15:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2245) Narayana TM should act upon wildfly suspend calls In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-2245. ---------------------------------- Resolution: Done This issue was incorporated by EAP7-459 Graceful Shutdown and Quiescing for Transactions > Narayana TM should act upon wildfly suspend calls > ------------------------------------------------- > > Key: JBTM-2245 > URL: https://issues.jboss.org/browse/JBTM-2245 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Application Server Integration, XTS > Affects Versions: 5.0.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > Wildfly now supports suspend [notifications | http://lists.jboss.org/pipermail/wildfly-dev/2014-August/002862.html] > The design discussion is [here| http://lists.jboss.org/pipermail/wildfly-dev/2014-June/002296.html] -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Jun 10 06:16:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sun, 10 Jun 2018 06:16:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2889) Include a vertx with STM quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2889: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Include a vertx with STM quickstart > ----------------------------------- > > Key: JBTM-2889 > URL: https://issues.jboss.org/browse/JBTM-2889 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator, STM > Affects Versions: 4.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.6.0.Final > > > It would be useful to include a quickstart that shows how to use STM with vertx -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Jun 10 06:22:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sun, 10 Jun 2018 06:22:00 -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 ] Michael Musgrove closed JBTM-2656. ---------------------------------- Resolution: Rejected I agree that the issue does not need to be fixed for compliance reasons and I am therefore rejecting this issue. > 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 > > 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 (v7.5.0#75005) From issues at jboss.org Mon Jun 11 03:37:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 11 Jun 2018 03:37:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3017) Provide a check to see if the last recovery scan "cleaned" the store. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1334 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Provide a check to see if the last recovery scan "cleaned" the store. > ---------------------------------------------------------------------- > > Key: JBTM-3017 > URL: https://issues.jboss.org/browse/JBTM-3017 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Recovery, Tooling > Affects Versions: 5.8.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > There are some recovery manager use cases where the user needs to know that the log store is empty and that all orphans have been detected (for example it is possible that some resource managers were not available during the last scan). > This feature would be particularly useful when running on OpenShift in order to determine when it is safe scale down and reclaim the space used by a pod. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 11 03:37:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 11 Jun 2018 03:37:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3031) Error messages for XTS registration is unprecise and hardly tracable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1333 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Error messages for XTS registration is unprecise and hardly tracable > -------------------------------------------------------------------- > > Key: JBTM-3031 > URL: https://issues.jboss.org/browse/JBTM-3031 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.8.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > Based on the changes made for JBTM-2928 : Provide WS-AT Integration with .NET we discussed with [~f_marchioni] there are gaps in understandability of error messages and it's hard to be traced. > The point is to report the XTS WS-AT register errors in better way. > Here is some of the points > {code} > Francesco Marchioni: In the test testAlreadyRegisteredProtocolIdentifierException > Francesco Marchioni: > ?? > ??????http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register<...> > ??????testAlreadyRegisteredProtocolIdentifierException > ??????http://localhost:8080/ws-c11/RegistrationService > ?????? > ????????
http://localhost:8080/ws-c11/RegistrationResponseService
> ??????
> ?????? > ????????
http://localhost:8080/ws-c11/CoordinationFaultService
> ??????
> ??????identifier > ??
> ?? > ?????? > ???????? http://wsc.example.org/already-registered-protocol-identifier > ???????? > ????????????http://wsc.example.org/protocol-participant-service > ???????????? > ?????????????? participant > ???????????? > ???????????? > ?????????????? wsc:ProtocolParticipantService > ???????????? > ???????? > ?????? > ?? >
> ?? > ??????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault > ??????urn:uuid:e4953fa1-0dc2-41cb-a565-0f446fa0e86c > ??????http://localhost:8080/ws-c11/CoordinationFaultService > ??????testAlreadyRegisteredProtocolIdentifierException > ?? > ?? > ?????? > ???????? wscoor:CannotRegister > ???????? Sender > ???????? > ????????????ARJUNA042081: Participant already registered > ???????? > ?????? > ?? > > Francesco Marchioni: The Exception message seem not correct: It's "Participant already registered" > {code} > {code} > Francesco Marchioni: RegistrationServiceTest there's one similar > Francesco Marchioni: > ????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault > ????urn:uuid:ff6387eb-df3a-4e97-9349-d39c042ac584 > ????http://localhost:8080/ws-c11/CoordinationFaultService > ????testUnknownCoordinationType > ?? > ?? > ???? > ??????wscoor:InvalidProtocol > ??????Sender > ?????? > ????????ARJUNA042082: Invalid protocol identifier > ?????? > ???? > ?? > > Francesco Marchioni: It says "invalid protocol identifier" for a test of unknownCoordinationType > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 11 04:07:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 11 Jun 2018 04:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2880) Refactor codebase to minimize usage of e.printStackTrace() call and change for using logger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1328 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Reopened) > Refactor codebase to minimize usage of e.printStackTrace() call and change for using logger > ------------------------------------------------------------------------------------------- > > Key: JBTM-2880 > URL: https://issues.jboss.org/browse/JBTM-2880 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Affects Versions: 5.5.6.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.later > > > The code base uses call `e.printStackTrace()` on several places. That usage should be minimized and used only when it's good reason for it. In general such calls should be replaced printing with `logger`, probably in level `WARN` with some additional information, why the stacktrace is printed - what error occured - included. > By quick check these are places where exception stack trace is printed directly to `stderr`. > {code} > -vertx/shared/src/main/java/ClientVerticle.java- > -vertx/shared/src/main/java/SampleVerticle2.java- > -vertx/shared/src/main/java/SampleVerticle1.java- > osgi/jta/src/main/java/org/jboss/narayana/osgi/jta/internal/ObjStoreBrowserImpl.java > XTS/WSAS/classes/com/arjuna/mwlabs/wsas/UserActivityImple.java > XTS/WSAS/classes/com/arjuna/mwlabs/wsas/activity/ActivityHandleImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf11/model/sagas/arjunacore/SagasHLSImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf11/model/twophase/arjunacore/TwoPhaseHLSImple.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/sagas/arjunacore/ParticipantRecord.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/sagas/arjunacore/CoordinatorControl.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/ParticipantRecord.java > XTS/WSCF/classes/com/arjuna/mwlabs/wscf/model/twophase/arjunacore/CoordinatorControl.java > XTS/WSCF/classes/com/arjuna/mw/wscf/utils/DomUtil.java > XTS/WSCF/classes/com/arjuna/mw/wscf/protocols/ProtocolManager.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/RegistrarImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/context/ArjunaContextImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/TransactionManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/UserTransactionImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/remote/UserTransactionStandaloneImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/participants/CleanupSynchronization.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/at/ContextFactoryImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/context/ArjunaContextImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/UserBusinessActivityImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/BusinessActivityManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/BAParticipantManagerImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/remote/UserBusinessActivityStandaloneImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/participants/CleanupSynchronization.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst11/ba/ContextFactoryImple.java > XTS/WSTX/classes/com/arjuna/mwlabs/wst/at/participants/DurableTwoPhaseCommitParticipant.java > XTS/localjunit/WSTX11-interop/src/main/java/com/jboss/transaction/txinterop/proxy/ProxyListenerService.java > XTS/localjunit/WSTFSC07-interop/src/main/java/com/jboss/transaction/wstf/proxy/ProxyListenerService.java > XTS/WS-T/dev/src/com/arjuna/schemas/ws/_2005/_10/wsarjtx/TerminationCoordinatorRPCService.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/CompletionStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/CompletionRPCStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/stub/BusinessActivityTerminatorRPCStub.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/TerminationCoordinatorRPCProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/CompletionCoordinatorProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/CompletionCoordinatorRPCProcessorImpl.java > XTS/WS-T/dev/src/com/arjuna/wst11/messaging/TerminationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/wsc11/messaging/ActivationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/wsc11/messaging/RegistrationCoordinatorProcessorImpl.java > XTS/WS-C/dev/src/com/arjuna/webservices/SoapFault.java > ArjunaJTA/jta/classes/com/arjuna/ats/jta/xa/XidImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/TransactionImporterImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/TransactionImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/subordinate/TransactionImple.java > ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/recovery/arjunacore/SubordinateJTAXAResourceOrphanFilter.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/DirectRecoverableConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ConnectionManager.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/ProvidedXADataSourceConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/IndirectRecoverableConnection.java > ArjunaJTA/jdbc/classes/com/arjuna/ats/internal/jdbc/recovery/JDBCXARecovery.java > blacktie/utils/cpp-plugin/src/main/java/org/jboss/narayana/blacktie/plugins/AddCommonSources.java > blacktie/jatmibroker-xatmi/src/main/java/org/jboss/narayana/blacktie/jatmibroker/core/server/SocketServer.java > blacktie/wildfly-blacktie/subsystem/src/main/java/org/codehaus/stomp/jms/ProtocolConverter.java > blacktie/blacktie-admin-services/src/main/java/org/jboss/narayana/blacktie/administration/core/AdministrationProxy.java > tools/src/main/java/io/narayana/perf/Measurement.java > rts/at/tx/src/main/java/org/jboss/jbossts/star/resource/RESTRecord.java > rts/at/tx/src/main/java/org/jboss/jbossts/star/service/Coordinator.java > txframework/src/main/java/org/jboss/narayana/txframework/impl/Participant.java > compensations/src/main/java/org/jboss/narayana/compensations/internal/ParticipantInterceptor.java > compensations/src/main/java/org/jboss/narayana/compensations/internal/ParticipantImpl.java > ArjunaCore/arjuna/services/classes/com/arjuna/ats/arjuna/services/recovery/RecoveryManagerService.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/utils/AndroidProcessId.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/abstractrecords/CadaverRecord.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/ShadowingStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/LogStore.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/AbstractRecord.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/coordinator/BasicAction.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/common/ObjectStoreEnvironmentBean.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/log/LogBrowser.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/stats/TxPerfGraph.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/tools/OTM.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/StateManager.java > ArjunaCore/arjuna/classes/com/arjuna/ats/arjuna/recovery/RecoveryManager.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jta/jca/XATerminator.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jts/jca/XATerminator.java > ArjunaJTS/integration/src/main/java/com/arjuna/ats/internal/jbossatx/jts/PropagationContextManager.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/jca/XATerminatorImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/BaseTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/TransactionImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/jca/coordinator/ServerTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/jca/SubordinateAtomicTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/TransactionImple.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/transaction/jts/subordinate/SubordinateAtomicTransaction.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/resources/jts/orbspecific/XAResourceRecord.java > ArjunaJTS/jtax/classes/com/arjuna/ats/internal/jta/recovery/jts/JCAServerTransactionRecoveryModule.java > ArjunaJTS/orbportability/classes/com/arjuna/orbportability/common/ant/IDLCompiler.java > ArjunaJTS/jts/services/classes/com/arjuna/ats/jts/services/transactionserver/TransactionServerService.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/utils/TxStoreLog.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/interposition/ServerControl.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/coordinator/ArjunaTransactionImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/jacorb/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/jacorb/recoverycoordinators/JacOrbRCServiceInit.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/ibmorb/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/javaidl/recoverycoordinators/ORBRunner.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/CurrentImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/TransactionFactoryImple.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/orbspecific/recovery/RecoveryEnablement.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/context/ContextManager.java > ArjunaJTS/jts/classes/com/arjuna/ats/internal/jts/resources/ExtendedResourceRecord.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/TransactionServer.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/jacorb/interceptors/interposition/InterpositionClientRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/jacorb/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/ibmorb/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/orbspecific/javaidl/interceptors/context/ContextServerRequestInterceptorImpl.java > ArjunaJTS/jts/classes/com/arjuna/ats/jts/ExplicitInterposition.java > STM/src/main/java/org/jboss/stm/internal/reflect/InvocationHandler.java > STM/src/main/java/org/jboss/stm/internal/proxy/OptimisticLockManagerProxy.java > STM/src/main/java/org/jboss/stm/internal/proxy/LockManagerProxy.java > STM/src/main/java/org/jboss/stm/internal/optimistic/OptimisticLockRecord.java > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 11 04:09:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 11 Jun 2018 04:09:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3031) Error messages for XTS registration is unprecise and hardly tracable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3031: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Error messages for XTS registration is unprecise and hardly tracable > -------------------------------------------------------------------- > > Key: JBTM-3031 > URL: https://issues.jboss.org/browse/JBTM-3031 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: XTS > Affects Versions: 5.8.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > Based on the changes made for JBTM-2928 : Provide WS-AT Integration with .NET we discussed with [~f_marchioni] there are gaps in understandability of error messages and it's hard to be traced. > The point is to report the XTS WS-AT register errors in better way. > Here is some of the points > {code} > Francesco Marchioni: In the test testAlreadyRegisteredProtocolIdentifierException > Francesco Marchioni: > ?? > ??????http://docs.oasis-open.org/ws-tx/wscoor/2006/06/Register<...> > ??????testAlreadyRegisteredProtocolIdentifierException > ??????http://localhost:8080/ws-c11/RegistrationService > ?????? > ????????
http://localhost:8080/ws-c11/RegistrationResponseService
> ??????
> ?????? > ????????
http://localhost:8080/ws-c11/CoordinationFaultService
> ??????
> ??????identifier > ??
> ?? > ?????? > ???????? http://wsc.example.org/already-registered-protocol-identifier > ???????? > ????????????http://wsc.example.org/protocol-participant-service > ???????????? > ?????????????? participant > ???????????? > ???????????? > ?????????????? wsc:ProtocolParticipantService > ???????????? > ???????? > ?????? > ?? >
> ?? > ??????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault > ??????urn:uuid:e4953fa1-0dc2-41cb-a565-0f446fa0e86c > ??????http://localhost:8080/ws-c11/CoordinationFaultService > ??????testAlreadyRegisteredProtocolIdentifierException > ?? > ?? > ?????? > ???????? wscoor:CannotRegister > ???????? Sender > ???????? > ????????????ARJUNA042081: Participant already registered > ???????? > ?????? > ?? > > Francesco Marchioni: The Exception message seem not correct: It's "Participant already registered" > {code} > {code} > Francesco Marchioni: RegistrationServiceTest there's one similar > Francesco Marchioni: > ????http://schemas.xmlsoap.org/wsdl/soap/envelope/fault > ????urn:uuid:ff6387eb-df3a-4e97-9349-d39c042ac584 > ????http://localhost:8080/ws-c11/CoordinationFaultService > ????testUnknownCoordinationType > ?? > ?? > ???? > ??????wscoor:InvalidProtocol > ??????Sender > ?????? > ????????ARJUNA042082: Invalid protocol identifier > ?????? > ???? > ?? > > Francesco Marchioni: It says "invalid protocol identifier" for a test of unknownCoordinationType > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 11 04:19:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 11 Jun 2018 04:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3020) Add ability for resources to indicate XA_RDONLY on end In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1327 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Add ability for resources to indicate XA_RDONLY on end > ------------------------------------------------------ > > Key: JBTM-3020 > URL: https://issues.jboss.org/browse/JBTM-3020 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: Ondra Chaloupka > Fix For: 5.next > > > As discussed in WFLY-10258 and https://developer.jboss.org/message/982097, this request is to add the ability for an XAResource to indicate (on end) that it has no committable work, which would act as a hint to order that XAResource at an earlier point of prepare processing, which will in turn increase the chances of a 1PC optimization occurring. > As expressed in the forum thread, the mechanism should not interfere with compatibility. One possible way to do this would be to introduce an enhanced subinterface of XAResource which includes a method like this: > {code:java} > int endWithResult(Xid xid, int flags) throws XAException; > {code} > The method behaves semantically identically to {{XAResource#end}} , except it would be allowed to return {{XA_RDONLY}} or {{XA_OK}}. A value of {{XA_RDONLY}} would indicate that the resource expects to return {{XA_RDONLY}} in response to a {{prepare}} call, whereas a value of {{XA_OK}} indicates that the resource's future {{prepare}} result cannot yet be decided or will be {{XA_OK}}. An invalid result should probably behave equivalently to an {{XAException}} being thrown by the {{end}} method. {{XAER_RMERR}} seems like a reasonable error code for this case. An alternative strategy would be to treat an invalid return value as being equivalent to {{XA_OK}}. > Since it's a subinterface of {{XAResource}}, it could also define the following default method: > {code:java} > default void end(Xid xid, int flags) throws XAException { > endWithResult(xid, flags); > } > {code} > This method would not need to be called by the TM, but would correctly satisfy the {{XAResource}} contract without requiring the user to implement the redundant method. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jun 15 03:58:00 2018 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 15 Jun 2018 03:58:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3032) Check the connection pool with JMX when using Transactional DataSource In-Reply-To: References: Message-ID: Amos Feng created JBTM-3032: ------------------------------- Summary: Check the connection pool with JMX when using Transactional DataSource Key: JBTM-3032 URL: https://issues.jboss.org/browse/JBTM-3032 Project: JBoss Transaction Manager Issue Type: Enhancement Components: Tomcat Reporter: Amos Feng Currently the common-dbcp2 only expose the org.apache.commons.dbcp2.PoolableConnectionMXBean for every database connection. And the customer want to check the connection pool with JMX just like org.apach.tomcat.jdbc.pool.jmx.ConnectionPoolMBean * getIdle() * getSize() * getActive() * getNumIdle() * getNumActibe() * getWaitCount() -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jun 15 03:58:00 2018 From: issues at jboss.org (Amos Feng (JIRA)) Date: Fri, 15 Jun 2018 03:58:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3032) Check the connection pool with JMX when using Transactional DataSource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng reassigned JBTM-3032: ------------------------------- Assignee: Amos Feng > Check the connection pool with JMX when using Transactional DataSource > ---------------------------------------------------------------------- > > Key: JBTM-3032 > URL: https://issues.jboss.org/browse/JBTM-3032 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Tomcat > Reporter: Amos Feng > Assignee: Amos Feng > > Currently the common-dbcp2 only expose the org.apache.commons.dbcp2.PoolableConnectionMXBean for every database connection. And the customer want to check the connection pool with JMX just like org.apach.tomcat.jdbc.pool.jmx.ConnectionPoolMBean > * getIdle() > * getSize() > * getActive() > * getNumIdle() > * getNumActibe() > * getWaitCount() -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jun 15 07:34:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 15 Jun 2018 07:34:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3033) Update the RecoveryMonitor documentation to include a verbose option In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-3033: -------------------------------------- Summary: Update the RecoveryMonitor documentation to include a verbose option Key: JBTM-3033 URL: https://issues.jboss.org/browse/JBTM-3033 Project: JBoss Transaction Manager Issue Type: Task Components: Documentation Affects Versions: 5.8.2.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next https://issues.jboss.org/browse/JBTM-3017 added a -verbose option to the RecoveryMonitor to provide an indication of whether there were any errors during the last recovery scan of XAResources. This option needs adding to the docs. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 18 08:13:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 18 Jun 2018 08:13:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3017) Provide a check to see if the last recovery scan "cleaned" the store. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3017: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done The fix detects and reports issues (via RecoveryMonitor) with XAResources (such as not being able to contact one of the configured resources). This is sufficient to ensure that all potential orphans were detected. If support for other transaction types such as subordinate transactions is required then a separate JIRA should be raised. > Provide a check to see if the last recovery scan "cleaned" the store. > ---------------------------------------------------------------------- > > Key: JBTM-3017 > URL: https://issues.jboss.org/browse/JBTM-3017 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Recovery, Tooling > Affects Versions: 5.8.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > There are some recovery manager use cases where the user needs to know that the log store is empty and that all orphans have been detected (for example it is possible that some resource managers were not available during the last scan). > This feature would be particularly useful when running on OpenShift in order to determine when it is safe scale down and reclaim the space used by a pod. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 18 09:21:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 18 Jun 2018 09:21:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3033) Update the RecoveryMonitor documentation to include a verbose option In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3033: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/documentation/pull/47 > Update the RecoveryMonitor documentation to include a verbose option > -------------------------------------------------------------------- > > Key: JBTM-3033 > URL: https://issues.jboss.org/browse/JBTM-3033 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation > Affects Versions: 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > https://issues.jboss.org/browse/JBTM-3017 added a -verbose option to the RecoveryMonitor to provide an indication of whether there were any errors during the last recovery scan of XAResources. This option needs adding to the docs. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 18 09:22:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 18 Jun 2018 09:22:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3033) Update the RecoveryMonitor documentation to include a verbose option In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3033: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Update the RecoveryMonitor documentation to include a verbose option > -------------------------------------------------------------------- > > Key: JBTM-3033 > URL: https://issues.jboss.org/browse/JBTM-3033 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Documentation > Affects Versions: 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > https://issues.jboss.org/browse/JBTM-3017 added a -verbose option to the RecoveryMonitor to provide an indication of whether there were any errors during the last recovery scan of XAResources. This option needs adding to the docs. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 18 11:50:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 18 Jun 2018 11:50:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3034) CMR recovery wrongly handles commit and rollback In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-3034: ------------------------------------- Summary: CMR recovery wrongly handles commit and rollback Key: JBTM-3034 URL: https://issues.jboss.org/browse/JBTM-3034 Project: JBoss Transaction Manager Issue Type: Bug Components: JTA Affects Versions: 5.8.1.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka The recovery of CMR works wrongly. For scenario I currently investigate there is issue the second resource beging committed and rolled-back too. # cmr resource prepare (no real action on the local transction) # xa resource prepare (prepared in real as XA) # cmr resource commit (commiting the local transaction) # JVM crash # expecting the xa resource being committed, but it's committed and immediatelly rolled-back. fortunatelly it seems it does not causes data consistency issue. This is similar to what was seen in issue https://issues.jboss.org/browse/JBEAP-6326 but not the same. The seems could be connected with fix for https://issues.jboss.org/browse/JBTM-2734. More investigation is needed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 19 00:43:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 19 Jun 2018 00:43:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3034) CMR recovery wrongly handles commit and rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592967#comment-13592967 ] Ondra Chaloupka commented on JBTM-3034: --------------------------------------- the wrong commit/rollback behaviour on the {{XAResource}} seems to be in the part of the recovery where {{AtomicActionRecoveryModule}} "commits" the CMR resource which is followed by {{XAResource}} commit and as next the {{XAResourceRecoveryModule}} forces to rollback during _bottomUp_ recovery by orphan detection. The recovery scan part from the WFLY server: {code} 2018-06-18 11:27:53,568 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) Periodic recovery first pass at Mon, 18 Jun 2018 11:27:53 2018-06-18 11:27:53,568 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) CommitMarkableResourceRecordRecoveryModule::periodicWorkFirstPass 2018-06-18 11:27:53,568 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) CommitMarkableResourceRecordRecoveryModule::connecting to: java:jboss/xa-datasources/CrashRecoveryDS 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) committedXidsToJndiNames.put< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80066:d6f3988:5b277ade:54, node_name=1, branch_uid=0:ffffc0a80066:d6f3988:5b277ade:5c, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS > java:jboss/xa-datasources/CrashRecoveryDS 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(/StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, InputObjectState Uid : 0:0:0:0:0 InputObjectState Type : null InputObjectState Size : 0 InputObjectState Buffer: , -1) 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.read_committed(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.read_state(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_SHADOW) 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 10) 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11) 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) - returning StateStatus.OS_UNKNOWN 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.read_state could not find committed or uncommitted state for 0:ffffc0a80066:d6f3988:5b277ade:54 instead found state StateStatus.OS_UNKNOWN 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.read_committed(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable) 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.read_state(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, StateType.OS_SHADOW) 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, 10) 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, 11) 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable) - returning StateStatus.OS_COMMITTED 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, 11) 2018-06-18 11:27:53,570 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.openAndLock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable/0_ffffc0a80066_d6f3988_5b277ade_54, FileLock.F_RDLCK, false) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.closeAndUnlock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable/0_ffffc0a80066_d6f3988_5b277ade_54, java.io.FileInputStream at 5e8b0ba, null) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) StateManager::StateManager( 0:ffffc0a80066:d6f3988:5b277ade:54 ) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) BasicAction::BasicAction(0:ffffc0a80066:d6f3988:5b277ade:54) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) StateManager.unpackHeader for object-id 0:ffffc0a80066:d6f3988:5b277ade:54 birth-date 1529314033528 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) Moving 0:ffffc0a80066:d6f3988:5b277ade:54 back to being an AA 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.read_committed(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.read_state(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, StateType.OS_SHADOW) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, 10) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, 11) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable) - returning StateStatus.OS_COMMITTED 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, 11) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.openAndLock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable/0_ffffc0a80066_d6f3988_5b277ade_54, FileLock.F_RDLCK, false) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.closeAndUnlock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable/0_ffffc0a80066_d6f3988_5b277ade_54, java.io.FileInputStream at 6907386a, null) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState(InputObjectState Uid : 0:ffffc0a80066:d6f3988:5b277ade:54 InputObjectState Type : /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable InputObjectState Size : 672 InputObjectState Buffer: ) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.write_committed(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.write_state(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11) 2018-06-18 11:27:53,571 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.openAndLock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/0_ffffc0a80066_d6f3988_5b277ade_54, FileLock.F_WRLCK, true) 2018-06-18 11:27:53,582 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.closeAndUnlock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/0_ffffc0a80066_d6f3988_5b277ade_54, null, java.io.FileOutputStream at 3a23442a) 2018-06-18 11:27:53,582 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.remove_committed(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable) 2018-06-18 11:27:53,582 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.remove_state(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,582 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, StateType.OS_SHADOW) 2018-06-18 11:27:53,582 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, 10) 2018-06-18 11:27:53,582 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,582 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, 11) 2018-06-18 11:27:53,582 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable) - returning StateStatus.OS_COMMITTED 2018-06-18 11:27:53,582 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,582 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, 11) 2018-06-18 11:27:53,582 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.openAndLock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable/0_ffffc0a80066_d6f3988_5b277ade_54, FileLock.F_WRLCK, false) 2018-06-18 11:27:53,582 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.closeAndUnlock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable/0_ffffc0a80066_d6f3988_5b277ade_54, null, null) 2018-06-18 11:27:53,582 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) processing /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction transactions 2018-06-18 11:27:53,582 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() 2018-06-18 11:27:53,582 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, InputObjectState Uid : 0:0:0:0:0 InputObjectState Type : null InputObjectState Size : 0 InputObjectState Buffer: , -1) 2018-06-18 11:27:53,582 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(/Recovery/TransactionStatusManager, InputObjectState Uid : 0:0:0:0:0 InputObjectState Type : null InputObjectState Size : 0 InputObjectState Buffer: , -1) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_SHADOW) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 10) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) - returning StateStatus.OS_COMMITTED 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.read_committed(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.read_state(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_SHADOW) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 10) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) - returning StateStatus.OS_COMMITTED 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.openAndLock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/0_ffffc0a80066_d6f3988_5b277ade_54, FileLock.F_RDLCK, false) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.closeAndUnlock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/0_ffffc0a80066_d6f3988_5b277ade_54, java.io.FileInputStream at 195c1bc0, null) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) StateManager::StateManager( 0:ffffc0a80066:d6f3988:5b277ade:54 ) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) BasicAction::BasicAction(0:ffffc0a80066:d6f3988:5b277ade:54) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) StateManager.unpackHeader for object-id 0:ffffc0a80066:d6f3988:5b277ade:54 birth-date 1529314033528 2018-06-18 11:27:53,583 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() 2018-06-18 11:27:53,583 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) AtomicActionRecoveryModule first pass 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, InputObjectState Uid : 0:0:0:0:0 InputObjectState Type : null InputObjectState Size : 0 InputObjectState Buffer: , -1) 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() 2018-06-18 11:27:53,583 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) processing /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction transactions 2018-06-18 11:27:53,583 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) found transaction 0:ffffc0a80066:d6f3988:5b277ade:54 2018-06-18 11:27:53,583 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) 2018-06-18 11:27:53,583 DEBUG [com.arjuna.ats.txoj] (Periodic Recovery) TORecoveryModule - first pass 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() 2018-06-18 11:27:53,583 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allTypes(InputObjectState Uid : 0:0:0:0:0 InputObjectState Type : null InputObjectState Size : 0 InputObjectState Buffer: ) 2018-06-18 11:27:53,584 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() 2018-06-18 11:27:53,584 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allTypes(OutputObjectState Uid : 0:ffffc0a80066:-74508445:5b277ae7:4f OutputObjectState Type : null OutputObjectState Size : 28 OutputObjectState Buffer: , StateManager) 2018-06-18 11:27:53,584 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allTypes(OutputObjectState Uid : 0:ffffc0a80066:-74508445:5b277ae7:4f OutputObjectState Type : null OutputObjectState Size : 60 OutputObjectState Buffer: , StateManager/BasicAction) 2018-06-18 11:27:53,584 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allTypes(OutputObjectState Uid : 0:ffffc0a80066:-74508445:5b277ae7:4f OutputObjectState Type : null OutputObjectState Size : 112 OutputObjectState Buffer: , StateManager/BasicAction/TwoPhaseCoordinator) 2018-06-18 11:27:53,584 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allTypes(OutputObjectState Uid : 0:ffffc0a80066:-74508445:5b277ae7:4f OutputObjectState Type : null OutputObjectState Size : 188 OutputObjectState Buffer: , StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable) 2018-06-18 11:27:53,584 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allTypes(OutputObjectState Uid : 0:ffffc0a80066:-74508445:5b277ae7:4f OutputObjectState Type : null OutputObjectState Size : 252 OutputObjectState Buffer: , StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) 2018-06-18 11:27:53,584 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allTypes(OutputObjectState Uid : 0:ffffc0a80066:-74508445:5b277ae7:4f OutputObjectState Type : null OutputObjectState Size : 264 OutputObjectState Buffer: , EISNAME) 2018-06-18 11:27:53,584 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() 2018-06-18 11:27:53,584 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(StateManager, InputObjectState Uid : 0:0:0:0:0 InputObjectState Type : null InputObjectState Size : 0 InputObjectState Buffer: , 2) 2018-06-18 11:27:53,584 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() 2018-06-18 11:27:53,584 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() 2018-06-18 11:27:53,584 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(StateManager/BasicAction, InputObjectState Uid : 0:0:0:0:0 InputObjectState Type : null InputObjectState Size : 0 InputObjectState Buffer: , 2) 2018-06-18 11:27:53,584 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() 2018-06-18 11:27:53,584 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() 2018-06-18 11:27:53,584 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(StateManager/BasicAction/TwoPhaseCoordinator, InputObjectState Uid : 0:0:0:0:0 InputObjectState Type : null InputObjectState Size : 0 InputObjectState Buffer: , 2) 2018-06-18 11:27:53,584 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() 2018-06-18 11:27:53,584 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() 2018-06-18 11:27:53,584 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, InputObjectState Uid : 0:0:0:0:0 InputObjectState Type : null InputObjectState Size : 0 InputObjectState Buffer: , 2) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, InputObjectState Uid : 0:0:0:0:0 InputObjectState Type : null InputObjectState Size : 0 InputObjectState Buffer: , 2) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_SHADOW) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 10) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffffc0a80066:d6f3988:5b277ade:54, StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) - returning StateStatus.OS_COMMITTED 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(EISNAME, InputObjectState Uid : 0:0:0:0:0 InputObjectState Type : null InputObjectState Size : 0 InputObjectState Buffer: , 2) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:62, EISNAME, StateType.OS_SHADOW) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:62, EISNAME, 10) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:62, EISNAME, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:62, EISNAME, 11) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffffc0a80066:d6f3988:5b277ade:62, EISNAME) - returning StateStatus.OS_COMMITTED 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:35, EISNAME, StateType.OS_SHADOW) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:35, EISNAME, 10) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:35, EISNAME, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:35, EISNAME, 11) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffffc0a80066:d6f3988:5b277ade:35, EISNAME) - returning StateStatus.OS_COMMITTED 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:44, EISNAME, StateType.OS_SHADOW) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:44, EISNAME, 10) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:44, EISNAME, StateType.OS_ORIGINAL) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:44, EISNAME, 11) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffffc0a80066:d6f3988:5b277ade:44, EISNAME) - returning StateStatus.OS_COMMITTED 2018-06-18 11:27:53,585 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA, InputObjectState Uid : 0:0:0:0:0 InputObjectState Type : null InputObjectState Size : 0 InputObjectState Buffer: , -1) 2018-06-18 11:27:53,585 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() 2018-06-18 11:27:53,586 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) 2018-06-18 11:27:53,586 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) XARecoveryModule state change IDLE->FIRST_PASS 2018-06-18 11:27:53,586 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Local XARecoveryModule - first pass 2018-06-18 11:27:53,586 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() 2018-06-18 11:27:53,586 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(/StateManager/AbstractRecord/XAResourceRecord, InputObjectState Uid : 0:0:0:0:0 InputObjectState Type : null InputObjectState Size : 0 InputObjectState Buffer: , -1) 2018-06-18 11:27:53,586 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() 2018-06-18 11:27:53,586 INFO [stdout] (Periodic Recovery) org.jboss.byteman.contrib.dtest.Instrumentor_org.jboss.as.test.jbossts.common.TestXAResourceRecovered_toString_remotetrace_entry execute() 2018-06-18 11:27:53,590 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) getXAResources() instance: TestXAResourceRecovered(TestXAResourceCommon(id:805, xid:null, timeout:0, prepareReturn:0)) 2018-06-18 11:27:53,590 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) xarecovery of org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 770ad4b7 2018-06-18 11:27:53,592 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Found 0 xids in doubt 2018-06-18 11:27:53,592 INFO [stdout] (Periodic Recovery) org.jboss.byteman.contrib.dtest.Instrumentor_org.jboss.as.test.jbossts.common.TestXAResourceRecovered_toString_remotetrace_entry execute() 2018-06-18 11:27:53,597 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) xarecovery of TestXAResourceRecovered(TestXAResourceCommon(id:805, xid:null, timeout:0, prepareReturn:0)) 2018-06-18 11:27:53,598 INFO [stdout] (Periodic Recovery) org.jboss.byteman.contrib.dtest.Instrumentor_org.jboss.as.test.jbossts.common.TestXAResourceRecovered_recover_remotetrace_entry execute() 2018-06-18 11:27:53,600 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecovered] (Periodic Recovery) TestXAResourceRecovered.recover(i=16777216)[id=805] 2018-06-18 11:27:53,600 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) recover() 2018-06-18 11:27:53,600 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) returning 1 Xids 2018-06-18 11:27:53,600 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) returning xid: < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80066:d6f3988:5b277ade:54, node_name=1, branch_uid=0:ffffc0a80066:d6f3988:5b277ade:63, subordinatenodename=null, eis_name=java:/TestXAResource > 2018-06-18 11:27:53,600 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Found 1 xids in doubt 2018-06-18 11:27:53,600 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Recovered: < 131077, 29, 36, 0000000000-1-1-64-8801021311157-1209139122-340008449, 0000000000-1-1-64-8801021311157-1209139122-340009900030000 > 2018-06-18 11:27:53,600 INFO [stdout] (Periodic Recovery) org.jboss.byteman.contrib.dtest.Instrumentor_org.jboss.as.test.jbossts.common.TestXAResourceRecovered_toString_remotetrace_entry execute() 2018-06-18 11:27:53,602 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids updateIfEquivalentRM1 TestXAResourceRecovered(TestXAResourceCommon(id:805, xid:null, timeout:0, prepareReturn:0)) 1529314073600 2018-06-18 11:27:53,602 INFO [stdout] (Periodic Recovery) org.jboss.byteman.contrib.dtest.Instrumentor_org.jboss.as.test.jbossts.common.TestXAResourceRecovered_isSameRM_remotetrace_entry execute() 2018-06-18 11:27:53,604 INFO [org.jboss.as.test.jbossts.common.TestXAResourceCommon] (Periodic Recovery) TestXAResourceCommon.isSameRM(xaResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 770ad4b7)[return 'false'][id=805] 2018-06-18 11:27:53,604 INFO [org.jboss.as.test.jbossts.common.TestXAResourceCommon] (Periodic Recovery) getJndiName()[return java:/TestXAResource][id=805] 2018-06-18 11:27:53,604 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) XARecoveryModule state change FIRST_PASS->BETWEEN_PASSES 2018-06-18 11:27:53,604 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) 2018-06-18 11:28:03,604 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) Periodic recovery second pass at Mon, 18 Jun 2018 11:28:03 2018-06-18 11:28:03,605 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() 2018-06-18 11:28:03,605 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, InputObjectState Uid : 0:0:0:0:0 InputObjectState Type : null InputObjectState Size : 0 InputObjectState Buffer: , -1) 2018-06-18 11:28:03,605 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() 2018-06-18 11:28:03,605 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) found transaction 0:ffffc0a80066:d6f3988:5b277ade:54 2018-06-18 11:28:03,605 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(/StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, InputObjectState Uid : 0:0:0:0:0 InputObjectState Type : null InputObjectState Size : 72 InputObjectState Buffer: , -1) 2018-06-18 11:28:03,605 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() 2018-06-18 11:28:03,605 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) 2018-06-18 11:28:03,605 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) AtomicActionRecoveryModule second pass 2018-06-18 11:28:03,605 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_SHADOW) 2018-06-18 11:28:03,605 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 10) 2018-06-18 11:28:03,605 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) 2018-06-18 11:28:03,605 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11) 2018-06-18 11:28:03,605 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) - returning StateStatus.OS_COMMITTED 2018-06-18 11:28:03,605 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState() 2018-06-18 11:28:03,606 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.allObjUids(/Recovery/TransactionStatusManager, InputObjectState Uid : 0:0:0:0:0 InputObjectState Type : null InputObjectState Size : 0 InputObjectState Buffer: , -1) 2018-06-18 11:28:03,606 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) OutputObjectState::OutputObjectState() 2018-06-18 11:28:03,606 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_SHADOW) 2018-06-18 11:28:03,606 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 10) 2018-06-18 11:28:03,606 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) 2018-06-18 11:28:03,606 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11) 2018-06-18 11:28:03,606 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) - returning StateStatus.OS_COMMITTED 2018-06-18 11:28:03,606 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) transaction type is /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction uid is 0:ffffc0a80066:d6f3988:5b277ade:54 ActionStatus is ActionStatus.COMMITTED in flight is false 2018-06-18 11:28:03,607 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) StateManager::StateManager( 0:ffffc0a80066:d6f3988:5b277ade:54 ) 2018-06-18 11:28:03,607 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) BasicAction::BasicAction(0:ffffc0a80066:d6f3988:5b277ade:54) 2018-06-18 11:28:03,607 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) BasicAction::activate() for action-id 0:ffffc0a80066:d6f3988:5b277ade:54 2018-06-18 11:28:03,607 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.read_committed(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) 2018-06-18 11:28:03,607 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.read_state(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) 2018-06-18 11:28:03,607 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_SHADOW) 2018-06-18 11:28:03,607 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 10) 2018-06-18 11:28:03,607 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) 2018-06-18 11:28:03,607 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11) 2018-06-18 11:28:03,607 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) - returning StateStatus.OS_COMMITTED 2018-06-18 11:28:03,607 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) 2018-06-18 11:28:03,607 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11) 2018-06-18 11:28:03,607 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.openAndLock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/0_ffffc0a80066_d6f3988_5b277ade_54, FileLock.F_RDLCK, false) 2018-06-18 11:28:03,607 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) InputObjectState::InputObjectState(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) 2018-06-18 11:28:03,607 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.closeAndUnlock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/0_ffffc0a80066_d6f3988_5b277ade_54, java.io.FileInputStream at 7dc3220f, null) 2018-06-18 11:28:03,607 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) BasicAction::restore_state () 2018-06-18 11:28:03,608 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) StateManager.unpackHeader for object-id 0:ffffc0a80066:d6f3988:5b277ade:54 birth-date 1529314033528 2018-06-18 11:28:03,608 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) Unpacked a 50 record 2018-06-18 11:28:03,608 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) StateManager::StateManager( 0:0:0:0:0 ) 2018-06-18 11:28:03,608 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) AbstractRecord::AbstractRecord () - crash recovery constructor 2018-06-18 11:28:03,608 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) CommitMarkableResourceRecord.CommitMarkableResourceRecord (), record id=-8000000000000000:-8000000000000000:-80000000:-80000000:-80000000 2018-06-18 11:28:03,608 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) unpack: java:jboss/xa-datasources/CrashRecoveryDS 2018-06-18 11:28:03,608 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) unpack: < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80066:d6f3988:5b277ade:54, node_name=1, branch_uid=0:ffffc0a80066:d6f3988:5b277ade:5c, subordinatenodename=null, eis_name=java:jboss/xa-datasources/CrashRecoveryDS > 2018-06-18 11:28:03,608 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/CommitMarkableResourceRecord for -8000000000000000:-8000000000000000:-80000000:-80000000:-80000000 2018-06-18 11:28:03,608 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) Unpacked a 171 record 2018-06-18 11:28:03,608 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) StateManager::StateManager( 0:0:0:0:0 ) 2018-06-18 11:28:03,608 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) AbstractRecord::AbstractRecord () - crash recovery constructor 2018-06-18 11:28:03,608 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecordList::insert(RecordList: -8000000000000000:-8000000000000000:-80000000:-80000000:-80000000) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffffc0a80066:d6f3988:5b277ade:64 2018-06-18 11:28:03,608 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) Unpacked a 463 record 2018-06-18 11:28:03,608 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) HeuristicList - Unpacked heuristic list size of 0 2018-06-18 11:28:03,608 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) Restored action status of ActionStatus.COMMITTING 6 2018-06-18 11:28:03,608 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) Restored action type Top-level 0 2018-06-18 11:28:03,608 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) Restored heuristic decision of TwoPhaseOutcome.PREPARE_OK 0 2018-06-18 11:28:03,609 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) RecoverAtomicAction.replayPhase2 recovering 0:ffffc0a80066:d6f3988:5b277ade:54 ActionStatus is ActionStatus.COMMITTED 2018-06-18 11:28:03,609 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) BasicAction::phase2Commit() for action-id 0:ffffc0a80066:d6f3988:5b277ade:54 2018-06-18 11:28:03,609 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) BasicAction::doCommit (com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord at 5f9d8871) 2018-06-18 11:28:03,609 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) CommitMarkableResourceRecord.topLevelCommit for com.arjuna.ats.internal.jta.resources.arjunacore.CommitMarkableResourceRecord at 5f9d8871, record id=-8000000000000000:-8000000000000000:-80000000:-80000000:-80000000 2018-06-18 11:28:03,609 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) BasicAction::doCommit() result for action-id (0:ffffc0a80066:d6f3988:5b277ade:54) on record id: (-8000000000000000:-8000000000000000:-80000000:-80000000:-80000000) is (TwoPhaseOutcome.FINISH_OK) node id: (1) 2018-06-18 11:28:03,609 INFO [stdout] (Periodic Recovery) org.jboss.byteman.contrib.dtest.Instrumentor_org.jboss.as.test.jbossts.common.TestXAResourceRecovered_toString_remotetrace_entry execute() 2018-06-18 11:28:03,613 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) BasicAction::doCommit (XAResourceRecord < resource:TestXAResourceRecovered(TestXAResourceCommon(id:805, xid:null, timeout:0, prepareReturn:0)), txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80066:d6f3988:5b277ade:54, node_name=1, branch_uid=0:ffffc0a80066:d6f3988:5b277ade:63, subordinatenodename=null, eis_name=java:/TestXAResource >, heuristic: TwoPhaseOutcome.FINISH_OK, product: Crash Recovery Test/EAP Test, jndiName: java:/TestXAResource com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ca8825d >) 2018-06-18 11:28:03,613 INFO [stdout] (Periodic Recovery) org.jboss.byteman.contrib.dtest.Instrumentor_org.jboss.as.test.jbossts.common.TestXAResourceRecovered_toString_remotetrace_entry execute() 2018-06-18 11:28:03,616 TRACE [com.arjuna.ats.jta] (Periodic Recovery) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:TestXAResourceRecovered(TestXAResourceCommon(id:805, xid:null, timeout:0, prepareReturn:0)), txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80066:d6f3988:5b277ade:54, node_name=1, branch_uid=0:ffffc0a80066:d6f3988:5b277ade:63, subordinatenodename=null, eis_name=java:/TestXAResource >, heuristic: TwoPhaseOutcome.FINISH_OK, product: Crash Recovery Test/EAP Test, jndiName: java:/TestXAResource com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord at 5ca8825d >, record id=0:ffffc0a80066:d6f3988:5b277ade:64 2018-06-18 11:28:03,618 INFO [stdout] (Periodic Recovery) Installed rule using default helper : org.jboss.byteman.contrib.dtest.Instrumentor_org.jboss.as.test.jbossts.common.TestXAResourceRecovered_commit_remotetrace_entry 2018-06-18 11:28:03,619 INFO [stdout] (Periodic Recovery) org.jboss.byteman.contrib.dtest.Instrumentor_org.jboss.as.test.jbossts.common.TestXAResourceRecovered_commit_remotetrace_entry execute() 2018-06-18 11:28:03,622 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecovered] (Periodic Recovery) TestXAResourceRecovered.commit(Xid=< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80066:d6f3988:5b277ade:54, node_name=1, branch_uid=0:ffffc0a80066:d6f3988:5b277ade:63, subordinatenodename=null, eis_name=java:/TestXAResource >, b=false)[id=805] 2018-06-18 11:28:03,622 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) removeLog(xid=< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80066:d6f3988:5b277ade:54, node_name=1, branch_uid=0:ffffc0a80066:d6f3988:5b277ade:63, subordinatenodename=null, eis_name=java:/TestXAResource > 2018-06-18 11:28:03,622 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) Using file /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/TestXAResourceStateStore/TestXAResource.ser for saving state of the org.jboss.as.test.jbossts.common.TestXAResource XA resource 2018-06-18 11:28:03,622 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) logging xids: [][number: 0] records to /home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/TestXAResourceStateStore/TestXAResource.ser 2018-06-18 11:28:03,623 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) BasicAction::doCommit() result for action-id (0:ffffc0a80066:d6f3988:5b277ade:54) on record id: (0:ffffc0a80066:d6f3988:5b277ade:64) is (TwoPhaseOutcome.FINISH_OK) node id: (1) 2018-06-18 11:28:03,623 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) BasicAction::updateState() for action-id 0:ffffc0a80066:d6f3988:5b277ade:54 2018-06-18 11:28:03,623 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.remove_committed(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) 2018-06-18 11:28:03,624 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.remove_state(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) 2018-06-18 11:28:03,624 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_SHADOW) 2018-06-18 11:28:03,624 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 10) 2018-06-18 11:28:03,624 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) 2018-06-18 11:28:03,624 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11) 2018-06-18 11:28:03,624 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) - returning StateStatus.OS_COMMITTED 2018-06-18 11:28:03,624 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) 2018-06-18 11:28:03,624 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11) 2018-06-18 11:28:03,624 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.openAndLock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/0_ffffc0a80066_d6f3988_5b277ade_54, FileLock.F_WRLCK, false) 2018-06-18 11:28:03,624 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.closeAndUnlock(/home/ochaloup/Transactions/eap-tests-transactions/jbossts/target/jbossas-jbossts/standalone/data/tx-object-store/ShadowNoFileLockStore/defaultStore/StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/0_ffffc0a80066_d6f3988_5b277ade_54, null, null) 2018-06-18 11:28:03,624 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) RecoverAtomicAction.replayPhase2( 0:ffffc0a80066:d6f3988:5b277ade:54 ) finished 2018-06-18 11:28:03,624 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) 2018-06-18 11:28:03,624 DEBUG [com.arjuna.ats.txoj] (Periodic Recovery) TORecoveryModule - second pass 2018-06-18 11:28:03,624 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) 2018-06-18 11:28:03,624 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) 2018-06-18 11:28:03,624 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) XARecoveryModule state change BETWEEN_PASSES->SECOND_PASS 2018-06-18 11:28:03,624 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Local XARecoveryModule - second pass 2018-06-18 11:28:03,624 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Local XARecoveryModule.transactionInitiatedRecovery completed 2018-06-18 11:28:03,624 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) xarecovery second pass of org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 770ad4b7 2018-06-18 11:28:03,624 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Have 0 Xids to recover on this pass. 2018-06-18 11:28:03,625 INFO [stdout] (Periodic Recovery) org.jboss.byteman.contrib.dtest.Instrumentor_org.jboss.as.test.jbossts.common.TestXAResourceRecovered_toString_remotetrace_entry execute() 2018-06-18 11:28:03,628 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) xarecovery second pass of TestXAResourceRecovered(TestXAResourceCommon(id:805, xid:null, timeout:0, prepareReturn:0)) 2018-06-18 11:28:03,629 INFO [stdout] (Periodic Recovery) org.jboss.byteman.contrib.dtest.Instrumentor_org.jboss.as.test.jbossts.common.TestXAResourceRecovered_toString_remotetrace_entry execute() 2018-06-18 11:28:03,632 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids _whenFirstSeen toRecover yes TestXAResourceRecovered(TestXAResourceCommon(id:805, xid:null, timeout:0, prepareReturn:0)) 1529314033525 === 1529314083628 2018-06-18 11:28:03,632 INFO [stdout] (Periodic Recovery) org.jboss.byteman.contrib.dtest.Instrumentor_org.jboss.as.test.jbossts.common.TestXAResourceRecovered_toString_remotetrace_entry execute() 2018-06-18 11:28:03,635 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids _whenFirstSeen toRecover no TestXAResourceRecovered(TestXAResourceCommon(id:805, xid:null, timeout:0, prepareReturn:0)) 1529314033525 === 1529314083628 2018-06-18 11:28:03,635 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Have 1 Xids to recover on this pass. 2018-06-18 11:28:03,635 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) StateManager::StateManager( 2, 0 ) 2018-06-18 11:28:03,635 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) BasicAction::BasicAction() 2018-06-18 11:28:03,636 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Checking whether Xid < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80066:d6f3988:5b277ade:54, node_name=1, branch_uid=0:ffffc0a80066:d6f3988:5b277ade:63, subordinatenodename=null, eis_name=java:/TestXAResource > exists in ObjectStore. 2018-06-18 11:28:03,636 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Looking for 0:ffffc0a80066:d6f3988:5b277ade:54 and /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction 2018-06-18 11:28:03,636 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.read_committed(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable) 2018-06-18 11:28:03,636 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.read_state(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, StateType.OS_ORIGINAL) 2018-06-18 11:28:03,636 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, StateType.OS_SHADOW) 2018-06-18 11:28:03,636 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, 10) 2018-06-18 11:28:03,636 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, StateType.OS_ORIGINAL) 2018-06-18 11:28:03,636 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable, 11) 2018-06-18 11:28:03,636 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicActionConnectable) - returning StateStatus.OS_UNKNOWN 2018-06-18 11:28:03,636 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.read_state could not find committed or uncommitted state for 0:ffffc0a80066:d6f3988:5b277ade:54 instead found state StateStatus.OS_UNKNOWN 2018-06-18 11:28:03,636 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_SHADOW) 2018-06-18 11:28:03,636 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 10) 2018-06-18 11:28:03,636 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, StateType.OS_ORIGINAL) 2018-06-18 11:28:03,636 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) FileSystemStore.genPathName(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction, 11) 2018-06-18 11:28:03,636 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) ShadowingStore.currentState(0:ffffc0a80066:d6f3988:5b277ade:54, /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction) - returning StateStatus.OS_UNKNOWN 2018-06-18 11:28:03,636 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) No record found for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80066:d6f3988:5b277ade:54, node_name=1, branch_uid=0:ffffc0a80066:d6f3988:5b277ade:63, subordinatenodename=null, eis_name=java:/TestXAResource > 2018-06-18 11:28:03,636 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTATransactionLogXAResourceOrphanFilter voted ABSTAIN 2018-06-18 11:28:03,637 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80066:d6f3988:5b277ade:54, node_name=1, branch_uid=0:ffffc0a80066:d6f3988:5b277ade:63, subordinatenodename=null, eis_name=java:/TestXAResource > is 1 2018-06-18 11:28:03,637 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK 2018-06-18 11:28:03,637 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) subordinate node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80066:d6f3988:5b277ade:54, node_name=1, branch_uid=0:ffffc0a80066:d6f3988:5b277ade:63, subordinatenodename=null, eis_name=java:/TestXAResource > is null 2018-06-18 11:28:03,637 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinateJTAXAResourceOrphanFilter voted ABSTAIN 2018-06-18 11:28:03,637 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) subordinate node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80066:d6f3988:5b277ade:54, node_name=1, branch_uid=0:ffffc0a80066:d6f3988:5b277ade:63, subordinatenodename=null, eis_name=java:/TestXAResource > is null 2018-06-18 11:28:03,638 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.SubordinationManagerXAResourceOrphanFilter voted ABSTAIN 2018-06-18 11:28:03,638 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80066:d6f3988:5b277ade:54, node_name=1, branch_uid=0:ffffc0a80066:d6f3988:5b277ade:63, subordinatenodename=null, eis_name=java:/TestXAResource > is 1 2018-06-18 11:28:03,638 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTAActionStatusServiceXAResourceOrphanFilter voted ABSTAIN 2018-06-18 11:28:03,638 INFO [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016013: Rolling back < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80066:d6f3988:5b277ade:54, node_name=1, branch_uid=0:ffffc0a80066:d6f3988:5b277ade:63, subordinatenodename=null, eis_name=java:/TestXAResource > 2018-06-18 11:28:03,640 INFO [stdout] (Periodic Recovery) Installed rule using default helper : org.jboss.byteman.contrib.dtest.Instrumentor_org.jboss.as.test.jbossts.common.TestXAResourceRecovered_rollback_remotetrace_entry 2018-06-18 11:28:03,641 INFO [stdout] (Periodic Recovery) org.jboss.byteman.contrib.dtest.Instrumentor_org.jboss.as.test.jbossts.common.TestXAResourceRecovered_rollback_remotetrace_entry execute() 2018-06-18 11:28:03,644 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecovered] (Periodic Recovery) TestXAResourceRecovered.rollback(Xid=< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80066:d6f3988:5b277ade:54, node_name=1, branch_uid=0:ffffc0a80066:d6f3988:5b277ade:63, subordinatenodename=null, eis_name=java:/TestXAResource >)[id=805] 2018-06-18 11:28:03,644 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) removeLog(xid=< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80066:d6f3988:5b277ade:54, node_name=1, branch_uid=0:ffffc0a80066:d6f3988:5b277ade:63, subordinatenodename=null, eis_name=java:/TestXAResource > 2018-06-18 11:28:03,644 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) no log present for < formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80066:d6f3988:5b277ade:54, node_name=1, branch_uid=0:ffffc0a80066:d6f3988:5b277ade:63, subordinatenodename=null, eis_name=java:/TestXAResource > 2018-06-18 11:28:03,644 INFO [stdout] (Periodic Recovery) org.jboss.byteman.contrib.dtest.Instrumentor_org.jboss.as.test.jbossts.common.TestXAResourceRecovered_recover_remotetrace_entry execute() 2018-06-18 11:28:03,646 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecovered] (Periodic Recovery) TestXAResourceRecovered.recover(i=8388608)[id=805] 2018-06-18 11:28:03,647 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) recover() 2018-06-18 11:28:03,647 INFO [org.jboss.as.test.jbossts.common.TestXAResourceRecoveryHelper] (Periodic Recovery) returning 0 Xids 2018-06-18 11:28:03,647 INFO [stdout] (Periodic Recovery) org.jboss.byteman.contrib.dtest.Instrumentor_org.jboss.as.test.jbossts.common.TestXAResourceRecovered_toString_remotetrace_entry execute() 2018-06-18 11:28:03,649 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check TestXAResourceRecovered(TestXAResourceCommon(id:805, xid:null, timeout:0, prepareReturn:0)) 1529314073600 1529314083647 false 2018-06-18 11:28:03,649 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids isStale Check org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper at 770ad4b7 1529314033516 1529314083649 true 2018-06-18 11:28:03,649 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Local XARecoveryModule.resourceInitiatedRecovery completed 2018-06-18 11:28:03,649 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) XARecoveryModule state change SECOND_PASS->IDLE 2018-06-18 11:28:03,649 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) 2018-06-18 11:28:03,649 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread Status <== INACTIVE 2018-06-18 11:28:03,649 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: scan thread signals listener worker 2018-06-18 11:28:03,649 DEBUG [com.arjuna.ats.arjuna] (Periodic Recovery) PeriodicRecovery: background thread backing off {code} > CMR recovery wrongly handles commit and rollback > ------------------------------------------------- > > Key: JBTM-3034 > URL: https://issues.jboss.org/browse/JBTM-3034 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.8.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > The recovery of CMR works wrongly. > For scenario I currently investigate there is issue the second resource beging committed and rolled-back too. > # cmr resource prepare (no real action on the local transction) > # xa resource prepare (prepared in real as XA) > # cmr resource commit (commiting the local transaction) > # JVM crash > # expecting the xa resource being committed, but it's committed and immediatelly rolled-back. fortunatelly it seems it does not causes data consistency issue. > This is similar to what was seen in issue https://issues.jboss.org/browse/JBEAP-6326 but not the same. The seems could be connected with fix for https://issues.jboss.org/browse/JBTM-2734. More investigation is needed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 19 05:48:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 19 Jun 2018 05:48:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3034) CMR recovery wrongly handles commit and rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3034: ---------------------------------- Description: The recovery of CMR works wrongly. For scenario I currently investigate there is issue the second resource beging committed and rolled-back too. # cmr resource prepare (no real action on the local transction) # xa resource prepare (prepared in real as XA) # cmr resource commit (commiting the local transaction) # JVM crash # expecting the xa resource being committed, but it's committed and immediatelly rolled-back. fortunatelly it seems it does not causes data consistency issue. This is similar to what was seen in issue https://issues.jboss.org/browse/JBEAP-6326 but not the same. The seems could be connected with fix for https://issues.jboss.org/browse/JBTM-2734. More investigation is needed. This is *regression* against EAP 7.0.0. The same scenario works in 7.0.0 smoothly. was: The recovery of CMR works wrongly. For scenario I currently investigate there is issue the second resource beging committed and rolled-back too. # cmr resource prepare (no real action on the local transction) # xa resource prepare (prepared in real as XA) # cmr resource commit (commiting the local transaction) # JVM crash # expecting the xa resource being committed, but it's committed and immediatelly rolled-back. fortunatelly it seems it does not causes data consistency issue. This is similar to what was seen in issue https://issues.jboss.org/browse/JBEAP-6326 but not the same. The seems could be connected with fix for https://issues.jboss.org/browse/JBTM-2734. More investigation is needed. > CMR recovery wrongly handles commit and rollback > ------------------------------------------------- > > Key: JBTM-3034 > URL: https://issues.jboss.org/browse/JBTM-3034 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.8.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > The recovery of CMR works wrongly. > For scenario I currently investigate there is issue the second resource beging committed and rolled-back too. > # cmr resource prepare (no real action on the local transction) > # xa resource prepare (prepared in real as XA) > # cmr resource commit (commiting the local transaction) > # JVM crash > # expecting the xa resource being committed, but it's committed and immediatelly rolled-back. fortunatelly it seems it does not causes data consistency issue. > This is similar to what was seen in issue https://issues.jboss.org/browse/JBEAP-6326 but not the same. The seems could be connected with fix for https://issues.jboss.org/browse/JBTM-2734. More investigation is needed. > This is *regression* against EAP 7.0.0. The same scenario works in 7.0.0 smoothly. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 20 12:26:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 20 Jun 2018 12:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3035) LRA context should propagate across non-LRA aware services In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-3035: -------------------------------------- Summary: LRA context should propagate across non-LRA aware services Key: JBTM-3035 URL: https://issues.jboss.org/browse/JBTM-3035 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.8.2.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next If you have a microservice A that wants to participate in an LRA and calls microservice B (which does not have specific LRA behaviour) and this calls microservice C (which does have specific LRA behaviour), then B should not need to be annotated with @LRA. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 20 13:08:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 20 Jun 2018 13:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3035) LRA context should propagate across non-LRA aware services In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594659#comment-13594659 ] Tom Jenkinson commented on JBTM-3035: ------------------------------------- Is there a spec reference for this? > LRA context should propagate across non-LRA aware services > ---------------------------------------------------------- > > Key: JBTM-3035 > URL: https://issues.jboss.org/browse/JBTM-3035 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > If you have a microservice A that wants to participate in an LRA and calls microservice B (which does not have specific LRA behaviour) and this calls microservice C (which does have specific LRA behaviour), then B should not need to be annotated with @LRA. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 20 13:32:00 2018 From: issues at jboss.org (Phillip Rhodes (JIRA)) Date: Wed, 20 Jun 2018 13:32:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3036) flight-service quickstart fails to build due to dependency failure In-Reply-To: References: Message-ID: Phillip Rhodes created JBTM-3036: ------------------------------------ Summary: flight-service quickstart fails to build due to dependency failure Key: JBTM-3036 URL: https://issues.jboss.org/browse/JBTM-3036 Project: JBoss Transaction Manager Issue Type: Bug Components: Build System Affects Versions: 5.8.2.Final Reporter: Phillip Rhodes [INFO] REST-AT to JTA Bridge Quickstart: JPA .............. SUCCESS [ 14.800 s] [INFO] REST-AT to JTA Bridge Quickstart: JMS .............. SUCCESS [ 0.587 s] [INFO] Narayana Quickstarts: REST-AT with undertow ........ SUCCESS [ 7.526 s] [INFO] RESTTX Quickstarts ................................. SUCCESS [ 0.000 s] [INFO] LRA Quickstart flight-service ...................... FAILURE [ 47.077 s] [INFO] LRA Quickstart hotel-service ....................... SKIPPED [INFO] LRA Quickstart trip-controller ..................... SKIPPED [INFO] LRA Quickstart trip-client ......................... SKIPPED [INFO] Run the example locally ............................ SKIPPED [INFO] RESTTX Quickstarts ................................. SKIPPED [INFO] xts-demo-all ....................................... SKIPPED [INFO] xts-demo-core ...................................... SKIPPED [INFO] xts-demo-webservices ............................... SKIPPED [INFO] xts-demo-war ....................................... SKIPPED [INFO] xts-demo-ear ....................................... SKIPPED [INFO] xts-demo-test ...................................... SKIPPED [INFO] JBoss Narayana Quickstarts: Simple WS-AT Web service, bridged to and from JTA. Bridges three servers SKIPPED [INFO] JBoss Narayana Quickstarts: Simple WS-AT Web service, bridged to and from JTA. Bridges three servers where one service invokes another SKIPPED [INFO] XTS Examples ....................................... SKIPPED [INFO] XTS over SSL Quickstart ............................ SKIPPED [INFO] setCheckedActionFactoryExample ..................... SKIPPED [INFO] optimistic ......................................... SKIPPED [INFO] pessimistic ........................................ SKIPPED [INFO] stm-jta ............................................ SKIPPED [INFO] JBoss Core Examples ................................ SKIPPED [INFO] narayana-quickstarts-all ........................... SKIPPED [INFO] jts-docker ......................................... SKIPPED [INFO] Narayana Quickstarts: JBTM and OSGI ................ SKIPPED [INFO] Narayana Quickstart: Standalone JTA 1.2 and Hibernate Quickstart SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 03:05 min [INFO] Finished at: 2018-06-20T17:19:36Z [INFO] Final Memory: 145M/738M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal on project flight-service: Could not resolve dependencies for project org.jboss.narayan a.quickstart.rts.lra:flight-service:war:5.8.2.Final: Could not find artifact org.eclipse.microprofile.lra:microprofile -lra-api:jar:1.0-SNAPSHOT in jboss-public-repository-group (https://repository.jboss.org/nexus/content/groups/public/) -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :flight-service -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 20 15:54:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 20 Jun 2018 15:54:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3036) flight-service quickstart fails to build due to dependency failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-3036: ----------------------------------- Assignee: Michael Musgrove > flight-service quickstart fails to build due to dependency failure > ------------------------------------------------------------------ > > Key: JBTM-3036 > URL: https://issues.jboss.org/browse/JBTM-3036 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Affects Versions: 5.8.2.Final > Reporter: Phillip Rhodes > Assignee: Michael Musgrove > > [INFO] REST-AT to JTA Bridge Quickstart: JPA .............. SUCCESS [ 14.800 s] > [INFO] REST-AT to JTA Bridge Quickstart: JMS .............. SUCCESS [ 0.587 s] > [INFO] Narayana Quickstarts: REST-AT with undertow ........ SUCCESS [ 7.526 s] > [INFO] RESTTX Quickstarts ................................. SUCCESS [ 0.000 s] > [INFO] LRA Quickstart flight-service ...................... FAILURE [ 47.077 s] > [INFO] LRA Quickstart hotel-service ....................... SKIPPED > [INFO] LRA Quickstart trip-controller ..................... SKIPPED > [INFO] LRA Quickstart trip-client ......................... SKIPPED > [INFO] Run the example locally ............................ SKIPPED > [INFO] RESTTX Quickstarts ................................. SKIPPED > [INFO] xts-demo-all ....................................... SKIPPED > [INFO] xts-demo-core ...................................... SKIPPED > [INFO] xts-demo-webservices ............................... SKIPPED > [INFO] xts-demo-war ....................................... SKIPPED > [INFO] xts-demo-ear ....................................... SKIPPED > [INFO] xts-demo-test ...................................... SKIPPED > [INFO] JBoss Narayana Quickstarts: Simple WS-AT Web service, bridged to and from JTA. Bridges three servers SKIPPED > [INFO] JBoss Narayana Quickstarts: Simple WS-AT Web service, bridged to and from JTA. Bridges three servers where one service invokes another SKIPPED > [INFO] XTS Examples ....................................... SKIPPED > [INFO] XTS over SSL Quickstart ............................ SKIPPED > [INFO] setCheckedActionFactoryExample ..................... SKIPPED > [INFO] optimistic ......................................... SKIPPED > [INFO] pessimistic ........................................ SKIPPED > [INFO] stm-jta ............................................ SKIPPED > [INFO] JBoss Core Examples ................................ SKIPPED > [INFO] narayana-quickstarts-all ........................... SKIPPED > [INFO] jts-docker ......................................... SKIPPED > [INFO] Narayana Quickstarts: JBTM and OSGI ................ SKIPPED > [INFO] Narayana Quickstart: Standalone JTA 1.2 and Hibernate Quickstart SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 03:05 min > [INFO] Finished at: 2018-06-20T17:19:36Z > [INFO] Final Memory: 145M/738M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal on project flight-service: Could not resolve dependencies for project org.jboss.narayan a.quickstart.rts.lra:flight-service:war:5.8.2.Final: Could not find artifact org.eclipse.microprofile.lra:microprofile -lra-api:jar:1.0-SNAPSHOT in jboss-public-repository-group (https://repository.jboss.org/nexus/content/groups/public/) -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please read the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the command > [ERROR] mvn -rf :flight-service -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 20 15:55:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 20 Jun 2018 15:55:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3036) flight-service quickstart fails to build due to dependency failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594713#comment-13594713 ] Tom Jenkinson commented on JBTM-3036: ------------------------------------- This is caused by the changes to using the eclipse microprofile LRA spec jar. Mike is there a good coordinate we can update this quickstart to use yet or do we have to recommend the workaround (to build https://github.com/eclipse/microprofile-lra by hand?) > flight-service quickstart fails to build due to dependency failure > ------------------------------------------------------------------ > > Key: JBTM-3036 > URL: https://issues.jboss.org/browse/JBTM-3036 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Affects Versions: 5.8.2.Final > Reporter: Phillip Rhodes > Assignee: Michael Musgrove > > [INFO] REST-AT to JTA Bridge Quickstart: JPA .............. SUCCESS [ 14.800 s] > [INFO] REST-AT to JTA Bridge Quickstart: JMS .............. SUCCESS [ 0.587 s] > [INFO] Narayana Quickstarts: REST-AT with undertow ........ SUCCESS [ 7.526 s] > [INFO] RESTTX Quickstarts ................................. SUCCESS [ 0.000 s] > [INFO] LRA Quickstart flight-service ...................... FAILURE [ 47.077 s] > [INFO] LRA Quickstart hotel-service ....................... SKIPPED > [INFO] LRA Quickstart trip-controller ..................... SKIPPED > [INFO] LRA Quickstart trip-client ......................... SKIPPED > [INFO] Run the example locally ............................ SKIPPED > [INFO] RESTTX Quickstarts ................................. SKIPPED > [INFO] xts-demo-all ....................................... SKIPPED > [INFO] xts-demo-core ...................................... SKIPPED > [INFO] xts-demo-webservices ............................... SKIPPED > [INFO] xts-demo-war ....................................... SKIPPED > [INFO] xts-demo-ear ....................................... SKIPPED > [INFO] xts-demo-test ...................................... SKIPPED > [INFO] JBoss Narayana Quickstarts: Simple WS-AT Web service, bridged to and from JTA. Bridges three servers SKIPPED > [INFO] JBoss Narayana Quickstarts: Simple WS-AT Web service, bridged to and from JTA. Bridges three servers where one service invokes another SKIPPED > [INFO] XTS Examples ....................................... SKIPPED > [INFO] XTS over SSL Quickstart ............................ SKIPPED > [INFO] setCheckedActionFactoryExample ..................... SKIPPED > [INFO] optimistic ......................................... SKIPPED > [INFO] pessimistic ........................................ SKIPPED > [INFO] stm-jta ............................................ SKIPPED > [INFO] JBoss Core Examples ................................ SKIPPED > [INFO] narayana-quickstarts-all ........................... SKIPPED > [INFO] jts-docker ......................................... SKIPPED > [INFO] Narayana Quickstarts: JBTM and OSGI ................ SKIPPED > [INFO] Narayana Quickstart: Standalone JTA 1.2 and Hibernate Quickstart SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 03:05 min > [INFO] Finished at: 2018-06-20T17:19:36Z > [INFO] Final Memory: 145M/738M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal on project flight-service: Could not resolve dependencies for project org.jboss.narayan a.quickstart.rts.lra:flight-service:war:5.8.2.Final: Could not find artifact org.eclipse.microprofile.lra:microprofile -lra-api:jar:1.0-SNAPSHOT in jboss-public-repository-group (https://repository.jboss.org/nexus/content/groups/public/) -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please read the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the command > [ERROR] mvn -rf :flight-service -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 20 22:57:00 2018 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 20 Jun 2018 22:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3032) Check the connection pool with JMX when using Transactional DataSource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13594760#comment-13594760 ] Amos Feng commented on JBTM-3032: --------------------------------- BasicDataSourceMXBean is used for exposing some information of the pool via JMX and it needs to set with 'jmxName', such as {code:xml} {code} > Check the connection pool with JMX when using Transactional DataSource > ---------------------------------------------------------------------- > > Key: JBTM-3032 > URL: https://issues.jboss.org/browse/JBTM-3032 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Tomcat > Reporter: Amos Feng > Assignee: Amos Feng > > Currently the common-dbcp2 only expose the org.apache.commons.dbcp2.PoolableConnectionMXBean for every database connection. And the customer want to check the connection pool with JMX just like org.apach.tomcat.jdbc.pool.jmx.ConnectionPoolMBean > * getIdle() > * getSize() > * getActive() > * getNumIdle() > * getNumActibe() > * getWaitCount() -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 20 23:02:00 2018 From: issues at jboss.org (Amos Feng (JIRA)) Date: Wed, 20 Jun 2018 23:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3032) Check the connection pool with JMX when using Transactional DataSource In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amos Feng resolved JBTM-3032. ----------------------------- Resolution: Explained > Check the connection pool with JMX when using Transactional DataSource > ---------------------------------------------------------------------- > > Key: JBTM-3032 > URL: https://issues.jboss.org/browse/JBTM-3032 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Tomcat > Reporter: Amos Feng > Assignee: Amos Feng > > Currently the common-dbcp2 only expose the org.apache.commons.dbcp2.PoolableConnectionMXBean for every database connection. And the customer want to check the connection pool with JMX just like org.apach.tomcat.jdbc.pool.jmx.ConnectionPoolMBean > * getIdle() > * getSize() > * getActive() > * getNumIdle() > * getNumActibe() > * getWaitCount() -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jun 21 15:40:00 2018 From: issues at jboss.org (Phillip Rhodes (JIRA)) Date: Thu, 21 Jun 2018 15:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3036) flight-service quickstart fails to build due to dependency failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13595322#comment-13595322 ] Phillip Rhodes commented on JBTM-3036: -------------------------------------- FWIW, I took a stab at getting it to build by building and installing lra separately, but no luck so far. There's still a mismatch somewhere that I ran out of time to chase down while I was working on this yesterday. > flight-service quickstart fails to build due to dependency failure > ------------------------------------------------------------------ > > Key: JBTM-3036 > URL: https://issues.jboss.org/browse/JBTM-3036 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Affects Versions: 5.8.2.Final > Reporter: Phillip Rhodes > Assignee: Michael Musgrove > > [INFO] REST-AT to JTA Bridge Quickstart: JPA .............. SUCCESS [ 14.800 s] > [INFO] REST-AT to JTA Bridge Quickstart: JMS .............. SUCCESS [ 0.587 s] > [INFO] Narayana Quickstarts: REST-AT with undertow ........ SUCCESS [ 7.526 s] > [INFO] RESTTX Quickstarts ................................. SUCCESS [ 0.000 s] > [INFO] LRA Quickstart flight-service ...................... FAILURE [ 47.077 s] > [INFO] LRA Quickstart hotel-service ....................... SKIPPED > [INFO] LRA Quickstart trip-controller ..................... SKIPPED > [INFO] LRA Quickstart trip-client ......................... SKIPPED > [INFO] Run the example locally ............................ SKIPPED > [INFO] RESTTX Quickstarts ................................. SKIPPED > [INFO] xts-demo-all ....................................... SKIPPED > [INFO] xts-demo-core ...................................... SKIPPED > [INFO] xts-demo-webservices ............................... SKIPPED > [INFO] xts-demo-war ....................................... SKIPPED > [INFO] xts-demo-ear ....................................... SKIPPED > [INFO] xts-demo-test ...................................... SKIPPED > [INFO] JBoss Narayana Quickstarts: Simple WS-AT Web service, bridged to and from JTA. Bridges three servers SKIPPED > [INFO] JBoss Narayana Quickstarts: Simple WS-AT Web service, bridged to and from JTA. Bridges three servers where one service invokes another SKIPPED > [INFO] XTS Examples ....................................... SKIPPED > [INFO] XTS over SSL Quickstart ............................ SKIPPED > [INFO] setCheckedActionFactoryExample ..................... SKIPPED > [INFO] optimistic ......................................... SKIPPED > [INFO] pessimistic ........................................ SKIPPED > [INFO] stm-jta ............................................ SKIPPED > [INFO] JBoss Core Examples ................................ SKIPPED > [INFO] narayana-quickstarts-all ........................... SKIPPED > [INFO] jts-docker ......................................... SKIPPED > [INFO] Narayana Quickstarts: JBTM and OSGI ................ SKIPPED > [INFO] Narayana Quickstart: Standalone JTA 1.2 and Hibernate Quickstart SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 03:05 min > [INFO] Finished at: 2018-06-20T17:19:36Z > [INFO] Final Memory: 145M/738M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal on project flight-service: Could not resolve dependencies for project org.jboss.narayan a.quickstart.rts.lra:flight-service:war:5.8.2.Final: Could not find artifact org.eclipse.microprofile.lra:microprofile -lra-api:jar:1.0-SNAPSHOT in jboss-public-repository-group (https://repository.jboss.org/nexus/content/groups/public/) -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please read the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the command > [ERROR] mvn -rf :flight-service -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jun 22 04:42:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 22 Jun 2018 04:42:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3036) flight-service quickstart fails to build due to dependency failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13595444#comment-13595444 ] Michael Musgrove commented on JBTM-3036: ---------------------------------------- In version 5.8.2 Final of the quickstarts the eclipse microprofile-lra artifact needs to be built first. I see we didn't include that step in the README, apologies for that, but if you run the quickstarts from the script it will be built automatically: {code} export WORKSPACE=`pwd`; ./scripts/hudson/quickstart.sh {code} We have since fixed it by making sure the dependency is available in a public repo so you wont have the same issue in version 5.8.3 Final > flight-service quickstart fails to build due to dependency failure > ------------------------------------------------------------------ > > Key: JBTM-3036 > URL: https://issues.jboss.org/browse/JBTM-3036 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Affects Versions: 5.8.2.Final > Reporter: Phillip Rhodes > Assignee: Michael Musgrove > > [INFO] REST-AT to JTA Bridge Quickstart: JPA .............. SUCCESS [ 14.800 s] > [INFO] REST-AT to JTA Bridge Quickstart: JMS .............. SUCCESS [ 0.587 s] > [INFO] Narayana Quickstarts: REST-AT with undertow ........ SUCCESS [ 7.526 s] > [INFO] RESTTX Quickstarts ................................. SUCCESS [ 0.000 s] > [INFO] LRA Quickstart flight-service ...................... FAILURE [ 47.077 s] > [INFO] LRA Quickstart hotel-service ....................... SKIPPED > [INFO] LRA Quickstart trip-controller ..................... SKIPPED > [INFO] LRA Quickstart trip-client ......................... SKIPPED > [INFO] Run the example locally ............................ SKIPPED > [INFO] RESTTX Quickstarts ................................. SKIPPED > [INFO] xts-demo-all ....................................... SKIPPED > [INFO] xts-demo-core ...................................... SKIPPED > [INFO] xts-demo-webservices ............................... SKIPPED > [INFO] xts-demo-war ....................................... SKIPPED > [INFO] xts-demo-ear ....................................... SKIPPED > [INFO] xts-demo-test ...................................... SKIPPED > [INFO] JBoss Narayana Quickstarts: Simple WS-AT Web service, bridged to and from JTA. Bridges three servers SKIPPED > [INFO] JBoss Narayana Quickstarts: Simple WS-AT Web service, bridged to and from JTA. Bridges three servers where one service invokes another SKIPPED > [INFO] XTS Examples ....................................... SKIPPED > [INFO] XTS over SSL Quickstart ............................ SKIPPED > [INFO] setCheckedActionFactoryExample ..................... SKIPPED > [INFO] optimistic ......................................... SKIPPED > [INFO] pessimistic ........................................ SKIPPED > [INFO] stm-jta ............................................ SKIPPED > [INFO] JBoss Core Examples ................................ SKIPPED > [INFO] narayana-quickstarts-all ........................... SKIPPED > [INFO] jts-docker ......................................... SKIPPED > [INFO] Narayana Quickstarts: JBTM and OSGI ................ SKIPPED > [INFO] Narayana Quickstart: Standalone JTA 1.2 and Hibernate Quickstart SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 03:05 min > [INFO] Finished at: 2018-06-20T17:19:36Z > [INFO] Final Memory: 145M/738M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal on project flight-service: Could not resolve dependencies for project org.jboss.narayan a.quickstart.rts.lra:flight-service:war:5.8.2.Final: Could not find artifact org.eclipse.microprofile.lra:microprofile -lra-api:jar:1.0-SNAPSHOT in jboss-public-repository-group (https://repository.jboss.org/nexus/content/groups/public/) -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please read the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the command > [ERROR] mvn -rf :flight-service -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jun 22 04:54:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 22 Jun 2018 04:54:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3036) flight-service quickstart fails to build due to dependency failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3036: ----------------------------------- Workaround: Workaround Exists So the simplest workaround is to build it manually: {code} git clone https://github.com/jbosstm/microprofile-lra cd microprofile-lra/ git checkout microprofile-lra cd .. ./build.sh -f microprofile-lra/pom.xml -B clean install {code} or you can run it from the script: export WORKSPACE=`pwd`; ./scripts/hudson/quickstart.sh > flight-service quickstart fails to build due to dependency failure > ------------------------------------------------------------------ > > Key: JBTM-3036 > URL: https://issues.jboss.org/browse/JBTM-3036 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Affects Versions: 5.8.2.Final > Reporter: Phillip Rhodes > Assignee: Michael Musgrove > > [INFO] REST-AT to JTA Bridge Quickstart: JPA .............. SUCCESS [ 14.800 s] > [INFO] REST-AT to JTA Bridge Quickstart: JMS .............. SUCCESS [ 0.587 s] > [INFO] Narayana Quickstarts: REST-AT with undertow ........ SUCCESS [ 7.526 s] > [INFO] RESTTX Quickstarts ................................. SUCCESS [ 0.000 s] > [INFO] LRA Quickstart flight-service ...................... FAILURE [ 47.077 s] > [INFO] LRA Quickstart hotel-service ....................... SKIPPED > [INFO] LRA Quickstart trip-controller ..................... SKIPPED > [INFO] LRA Quickstart trip-client ......................... SKIPPED > [INFO] Run the example locally ............................ SKIPPED > [INFO] RESTTX Quickstarts ................................. SKIPPED > [INFO] xts-demo-all ....................................... SKIPPED > [INFO] xts-demo-core ...................................... SKIPPED > [INFO] xts-demo-webservices ............................... SKIPPED > [INFO] xts-demo-war ....................................... SKIPPED > [INFO] xts-demo-ear ....................................... SKIPPED > [INFO] xts-demo-test ...................................... SKIPPED > [INFO] JBoss Narayana Quickstarts: Simple WS-AT Web service, bridged to and from JTA. Bridges three servers SKIPPED > [INFO] JBoss Narayana Quickstarts: Simple WS-AT Web service, bridged to and from JTA. Bridges three servers where one service invokes another SKIPPED > [INFO] XTS Examples ....................................... SKIPPED > [INFO] XTS over SSL Quickstart ............................ SKIPPED > [INFO] setCheckedActionFactoryExample ..................... SKIPPED > [INFO] optimistic ......................................... SKIPPED > [INFO] pessimistic ........................................ SKIPPED > [INFO] stm-jta ............................................ SKIPPED > [INFO] JBoss Core Examples ................................ SKIPPED > [INFO] narayana-quickstarts-all ........................... SKIPPED > [INFO] jts-docker ......................................... SKIPPED > [INFO] Narayana Quickstarts: JBTM and OSGI ................ SKIPPED > [INFO] Narayana Quickstart: Standalone JTA 1.2 and Hibernate Quickstart SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 03:05 min > [INFO] Finished at: 2018-06-20T17:19:36Z > [INFO] Final Memory: 145M/738M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal on project flight-service: Could not resolve dependencies for project org.jboss.narayan a.quickstart.rts.lra:flight-service:war:5.8.2.Final: Could not find artifact org.eclipse.microprofile.lra:microprofile -lra-api:jar:1.0-SNAPSHOT in jboss-public-repository-group (https://repository.jboss.org/nexus/content/groups/public/) -> [Help 1] > [ERROR] > [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. > [ERROR] Re-run Maven using the -X switch to enable full debug logging. > [ERROR] > [ERROR] For more information about the errors and possible solutions, please read the following articles: > [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException > [ERROR] > [ERROR] After correcting the problems, you can resume the build with the command > [ERROR] mvn -rf :flight-service -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jun 22 19:31:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 22 Jun 2018 19:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3035) LRA context should propagate across non-LRA aware services In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3035: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1335 > LRA context should propagate across non-LRA aware services > ---------------------------------------------------------- > > Key: JBTM-3035 > URL: https://issues.jboss.org/browse/JBTM-3035 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > If you have a microservice A that wants to participate in an LRA and calls microservice B (which does not have specific LRA behaviour) and this calls microservice C (which does have specific LRA behaviour), then B should not need to be annotated with @LRA. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jun 22 19:31:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 22 Jun 2018 19:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3035) LRA context should propagate across non-LRA aware services In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13595839#comment-13595839 ] Michael Musgrove commented on JBTM-3035: ---------------------------------------- https://github.com/eclipse/microprofile-lra/issues/7 > LRA context should propagate across non-LRA aware services > ---------------------------------------------------------- > > Key: JBTM-3035 > URL: https://issues.jboss.org/browse/JBTM-3035 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > If you have a microservice A that wants to participate in an LRA and calls microservice B (which does not have specific LRA behaviour) and this calls microservice C (which does have specific LRA behaviour), then B should not need to be annotated with @LRA. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sat Jun 23 10:23:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sat, 23 Jun 2018 10:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3035) LRA context should propagate across non-LRA aware services In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3035: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done The associated spec PR is https://github.com/eclipse/microprofile-lra/pull/10 > LRA context should propagate across non-LRA aware services > ---------------------------------------------------------- > > Key: JBTM-3035 > URL: https://issues.jboss.org/browse/JBTM-3035 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > If you have a microservice A that wants to participate in an LRA and calls microservice B (which does not have specific LRA behaviour) and this calls microservice C (which does have specific LRA behaviour), then B should not need to be annotated with @LRA. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sat Jun 23 10:24:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sat, 23 Jun 2018 10:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3035) LRA context should propagate across non-LRA aware services In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3035: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/1335, https://github.com/eclipse/microprofile-lra/pull/10 (was: https://github.com/jbosstm/narayana/pull/1335) > LRA context should propagate across non-LRA aware services > ---------------------------------------------------------- > > Key: JBTM-3035 > URL: https://issues.jboss.org/browse/JBTM-3035 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > If you have a microservice A that wants to participate in an LRA and calls microservice B (which does not have specific LRA behaviour) and this calls microservice C (which does have specific LRA behaviour), then B should not need to be annotated with @LRA. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sat Jun 23 10:43:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sat, 23 Jun 2018 10:43:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3037) LRA context is not always removed if the LRA is ended In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-3037: -------------------------------------- Summary: LRA context is not always removed if the LRA is ended Key: JBTM-3037 URL: https://issues.jboss.org/browse/JBTM-3037 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.8.2.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The following scenario leaves the LRA context still current: start an LRA call a service annotated with, for example, {code} @LRA(value = LRA.Type.REQUIRED, cancelOn = {Response.Status.NOT_FOUND}) {/code} If the invoked method returns the NOT_FOUND status then the LRA is automatically terminated. When the request returns to the client there should be no current LRA context active. The issue here is that the next request that the client makes may still have the old LRA still associated. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Jun 24 03:29:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sun, 24 Jun 2018 03:29:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3038) Include the checkstyle plugin in LRA maven poms In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-3038: -------------------------------------- Summary: Include the checkstyle plugin in LRA maven poms Key: JBTM-3038 URL: https://issues.jboss.org/browse/JBTM-3038 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.8.2.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Priority: Optional Fix For: 5.next To achieve a level of consistency of code it would be advantageous to include a formal set of checkstyle rules in this project. Since a primary user of the LRA coordinator and LRA APIs are microprofile-lra and thorntail it makes sense to use the ruleset from those projects. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Jun 24 04:02:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sun, 24 Jun 2018 04:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3038) Include the checkstyle plugin in LRA maven poms In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3038: ----------------------------------- Description: To achieve a level of consistency of code it would be advantageous to include a formal set of checkstyle rules in this project. Since a primary user of the LRA coordinator and LRA APIs are microprofile-lra and thorntail it makes sense to use the ruleset from one of those projects. For example, thorntail uses: {code} org.wildfly.swarm checkstyle-config 1 {code} was: To achieve a level of consistency of code it would be advantageous to include a formal set of checkstyle rules in this project. Since a primary user of the LRA coordinator and LRA APIs are microprofile-lra and thorntail it makes sense to use the ruleset from those projects. > Include the checkstyle plugin in LRA maven poms > ----------------------------------------------- > > Key: JBTM-3038 > URL: https://issues.jboss.org/browse/JBTM-3038 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > To achieve a level of consistency of code it would be advantageous to include a formal set of checkstyle rules in this project. > Since a primary user of the LRA coordinator and LRA APIs are microprofile-lra and thorntail it makes sense to use the ruleset from one of those projects. For example, thorntail uses: > {code} > > > org.wildfly.swarm > checkstyle-config > 1 > > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 25 05:00:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 25 Jun 2018 05:00:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3034) CMR recovery wrongly handles commit and rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13596002#comment-13596002 ] Ondra Chaloupka commented on JBTM-3034: --------------------------------------- After more investigation I found the observed issues is the same in all cases. The CMR which is committed then causes the resource is called to be rolled-back too. The regression seems to be caused by the fact that the {{XAResource}} is withdrawn from the {{XAResourceRecord}} https://github.com/jbosstm/narayana/blob/5.8.2.Final/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/resources/arjunacore/XAResourceRecord.java#L1254 during recovery (in second phase by {{AtomicActionRecoveryModule}}) and the {{_xidScans}} is not updated with that fact (https://github.com/jbosstm/narayana/blob/5.8.2.Final/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/recovery/arjunacore/XARecoveryModule.java#L289). This was done intentionally for {{XATerminator}} recovery does not add warnings {{noxaresource}} (https://github.com/jbosstm/narayana/pull/1059/files#diff-8487f43e773b3321c5396187b559bfffL261) but it seems not correct from CMR point of view. > CMR recovery wrongly handles commit and rollback > ------------------------------------------------- > > Key: JBTM-3034 > URL: https://issues.jboss.org/browse/JBTM-3034 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.8.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > The recovery of CMR works wrongly. > For scenario I currently investigate there is issue the second resource beging committed and rolled-back too. > # cmr resource prepare (no real action on the local transction) > # xa resource prepare (prepared in real as XA) > # cmr resource commit (commiting the local transaction) > # JVM crash > # expecting the xa resource being committed, but it's committed and immediatelly rolled-back. fortunatelly it seems it does not causes data consistency issue. > This is similar to what was seen in issue https://issues.jboss.org/browse/JBEAP-6326 but not the same. The seems could be connected with fix for https://issues.jboss.org/browse/JBTM-2734. More investigation is needed. > This is *regression* against EAP 7.0.0. The same scenario works in 7.0.0 smoothly. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 25 05:31:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 25 Jun 2018 05:31:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3034) CMR recovery wrongly handles commit and rollback In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-3034: ---------------------------------- Forum Reference: https://developer.jboss.org/message/983627#983627 > CMR recovery wrongly handles commit and rollback > ------------------------------------------------- > > Key: JBTM-3034 > URL: https://issues.jboss.org/browse/JBTM-3034 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.8.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > The recovery of CMR works wrongly. > For scenario I currently investigate there is issue the second resource beging committed and rolled-back too. > # cmr resource prepare (no real action on the local transction) > # xa resource prepare (prepared in real as XA) > # cmr resource commit (commiting the local transaction) > # JVM crash > # expecting the xa resource being committed, but it's committed and immediatelly rolled-back. fortunatelly it seems it does not causes data consistency issue. > This is similar to what was seen in issue https://issues.jboss.org/browse/JBEAP-6326 but not the same. The seems could be connected with fix for https://issues.jboss.org/browse/JBTM-2734. More investigation is needed. > This is *regression* against EAP 7.0.0. The same scenario works in 7.0.0 smoothly. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jun 25 07:22:11 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 25 Jun 2018 07:22:11 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3038) Include the checkstyle plugin in LRA maven poms In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3038: ----------------------------------- Description: To achieve a level of consistency of code it would be advantageous to include a formal set of checkstyle rules in this project. Since a primary user of the LRA coordinator and LRA APIs are microprofile-lra and thorntail it makes sense to use the ruleset from one of those projects. For example, thorntail uses: {code} org.wildfly.swarm checkstyle-config 1 {code} Note that thorntail and wildfly appear to use the same ruleset. was: To achieve a level of consistency of code it would be advantageous to include a formal set of checkstyle rules in this project. Since a primary user of the LRA coordinator and LRA APIs are microprofile-lra and thorntail it makes sense to use the ruleset from one of those projects. For example, thorntail uses: {code} org.wildfly.swarm checkstyle-config 1 {code} > Include the checkstyle plugin in LRA maven poms > ----------------------------------------------- > > Key: JBTM-3038 > URL: https://issues.jboss.org/browse/JBTM-3038 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > To achieve a level of consistency of code it would be advantageous to include a formal set of checkstyle rules in this project. > Since a primary user of the LRA coordinator and LRA APIs are microprofile-lra and thorntail it makes sense to use the ruleset from one of those projects. For example, thorntail uses: > {code} > > > org.wildfly.swarm > checkstyle-config > 1 > > {code} > Note that thorntail and wildfly appear to use the same ruleset. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 26 05:25:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 26 Jun 2018 05:25:01 -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 reassigned JBTM-2685: ----------------------------------- Assignee: Amos Feng (was: Michael Musgrove) > 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: Amos Feng > Priority: Critical > > **(some commits that reference this issue are actually for https://issues.jboss.org/browse/JBTM-2955)** > Get the latest build from https://jdk9.java.net/download/ and check for any issues. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 26 08:12:01 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 26 Jun 2018 08:12:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3038) Include the checkstyle plugin in LRA maven poms In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3038: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1337 > Include the checkstyle plugin in LRA maven poms > ----------------------------------------------- > > Key: JBTM-3038 > URL: https://issues.jboss.org/browse/JBTM-3038 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > To achieve a level of consistency of code it would be advantageous to include a formal set of checkstyle rules in this project. > Since a primary user of the LRA coordinator and LRA APIs are microprofile-lra and thorntail it makes sense to use the ruleset from one of those projects. For example, thorntail uses: > {code} > > > org.wildfly.swarm > checkstyle-config > 1 > > {code} > Note that thorntail and wildfly appear to use the same ruleset. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 26 08:13:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 26 Jun 2018 08:13:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3038) Include the checkstyle plugin in LRA maven poms In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3038: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Include the checkstyle plugin in LRA maven poms > ----------------------------------------------- > > Key: JBTM-3038 > URL: https://issues.jboss.org/browse/JBTM-3038 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > To achieve a level of consistency of code it would be advantageous to include a formal set of checkstyle rules in this project. > Since a primary user of the LRA coordinator and LRA APIs are microprofile-lra and thorntail it makes sense to use the ruleset from one of those projects. For example, thorntail uses: > {code} > > > org.wildfly.swarm > checkstyle-config > 1 > > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 26 08:13:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 26 Jun 2018 08:13:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3038) Include the checkstyle plugin in LRA maven poms In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3038: ----------------------------------- Description: To achieve a level of consistency of code it would be advantageous to include a formal set of checkstyle rules in this project. Since a primary user of the LRA coordinator and LRA APIs are microprofile-lra and thorntail it makes sense to use the ruleset from one of those projects. For example, thorntail uses: {code} org.wildfly.swarm checkstyle-config 1 {code} was: To achieve a level of consistency of code it would be advantageous to include a formal set of checkstyle rules in this project. Since a primary user of the LRA coordinator and LRA APIs are microprofile-lra and thorntail it makes sense to use the ruleset from one of those projects. For example, thorntail uses: {code} org.wildfly.swarm checkstyle-config 1 {code} Note that thorntail and wildfly appear to use the same ruleset. > Include the checkstyle plugin in LRA maven poms > ----------------------------------------------- > > Key: JBTM-3038 > URL: https://issues.jboss.org/browse/JBTM-3038 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > To achieve a level of consistency of code it would be advantageous to include a formal set of checkstyle rules in this project. > Since a primary user of the LRA coordinator and LRA APIs are microprofile-lra and thorntail it makes sense to use the ruleset from one of those projects. For example, thorntail uses: > {code} > > > org.wildfly.swarm > checkstyle-config > 1 > > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jun 26 11:57:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 26 Jun 2018 11:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3017) Provide a check to see if the last recovery scan "cleaned" the store. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reopened JBTM-3017: ------------------------------------ I have reopened JBTM-3017 so that the program returns a standard code according to the conventions defined in System.exit(n). > Provide a check to see if the last recovery scan "cleaned" the store. > ---------------------------------------------------------------------- > > Key: JBTM-3017 > URL: https://issues.jboss.org/browse/JBTM-3017 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Recovery, Tooling > Affects Versions: 5.8.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > There are some recovery manager use cases where the user needs to know that the log store is empty and that all orphans have been detected (for example it is possible that some resource managers were not available during the last scan). > This feature would be particularly useful when running on OpenShift in order to determine when it is safe scale down and reclaim the space used by a pod. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jun 27 13:34:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 27 Jun 2018 13:34:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3039) Add a bean method to report whether or not all XAResources were contaced during the last recovery scan In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-3039: -------------------------------------- Summary: Add a bean method to report whether or not all XAResources were contaced during the last recovery scan Key: JBTM-3039 URL: https://issues.jboss.org/browse/JBTM-3039 Project: JBoss Transaction Manager Issue Type: Enhancement Components: Recovery Affects Versions: 5.8.2.Final, 5.5.30.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.5.31.Final, 5.next There are some recovery manager use cases where the user needs to know that all orphans have been detected (for example it is possible that some registered resource managers were not contactable during the last scan). This feature would be particularly useful when running on OpenShift in order to determine when it is safe to scale down and reclaim the space used by a pod. The proposal is to validate that the recover() method was successfully invoked on all currently registered resources. The proposed new method should report whether or not there were any errors or warnings during last recovery scan made by the XARecoveryModule. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jun 28 04:52:00 2018 From: issues at jboss.org (Jean-Frederic Clere (JIRA)) Date: Thu, 28 Jun 2018 04:52:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3030) Moving the tomcat-jta to the JWS web-servers repo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13598162#comment-13598162 ] Jean-Frederic Clere commented on JBTM-3030: ------------------------------------------- OK let's move it to https://github.com/web-servers and add [~zhfeng] to our people. [~zhfeng] any other committers to add? > Moving the tomcat-jta to the JWS web-servers repo > ------------------------------------------------- > > Key: JBTM-3030 > URL: https://issues.jboss.org/browse/JBTM-3030 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Tomcat > Reporter: Amos Feng > Assignee: Amos Feng > -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jun 28 05:00:00 2018 From: issues at jboss.org (Amos Feng (JIRA)) Date: Thu, 28 Jun 2018 05:00:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3030) Moving the tomcat-jta to the JWS web-servers repo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13598168#comment-13598168 ] Amos Feng commented on JBTM-3030: --------------------------------- Thanks [~jfclere], no other ones need to be added. > Moving the tomcat-jta to the JWS web-servers repo > ------------------------------------------------- > > Key: JBTM-3030 > URL: https://issues.jboss.org/browse/JBTM-3030 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Tomcat > Reporter: Amos Feng > Assignee: Amos Feng > -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jun 28 05:55:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 28 Jun 2018 05:55:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3017) Provide a check to see if the last recovery scan "cleaned" the store. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove resolved JBTM-3017. ------------------------------------ Resolution: Done Closing again since the requirement is for a programmatic mechanism to obtain the status of the last scan and this feature already exists in the current fix (by calling jtaLogger.isRecoveryProblems()). > Provide a check to see if the last recovery scan "cleaned" the store. > ---------------------------------------------------------------------- > > Key: JBTM-3017 > URL: https://issues.jboss.org/browse/JBTM-3017 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Recovery, Tooling > Affects Versions: 5.8.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > There are some recovery manager use cases where the user needs to know that the log store is empty and that all orphans have been detected (for example it is possible that some resource managers were not available during the last scan). > This feature would be particularly useful when running on OpenShift in order to determine when it is safe scale down and reclaim the space used by a pod. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jun 28 06:03:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 28 Jun 2018 06:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3039) Add a bean method to report whether or not all XAResources were contaced during the last recovery scan In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove closed JBTM-3039. ---------------------------------- Resolution: Rejected Rejected since the functionality is already provided by https://issues.jboss.org/browse/JBTM-3017 > Add a bean method to report whether or not all XAResources were contaced during the last recovery scan > ------------------------------------------------------------------------------------------------------ > > Key: JBTM-3039 > URL: https://issues.jboss.org/browse/JBTM-3039 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Affects Versions: 5.5.30.Final, 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.5.31.Final, 5.next > > > There are some recovery manager use cases where the user needs to know that all orphans have been detected (for example it is possible that some registered resource managers were not contactable during the last scan). > This feature would be particularly useful when running on OpenShift in order to determine when it is safe to scale down and reclaim the space used by a pod. > The proposal is to validate that the recover() method was successfully invoked on all currently registered resources. The proposed new method should report whether or not there were any errors or warnings during last recovery scan made by the XARecoveryModule. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jun 28 08:46:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 28 Jun 2018 08:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3017) Provide a check to see if the last recovery scan "cleaned" the store. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reopened JBTM-3017: ------------------------------------ Reopened because the recoveryProblems flag was not getting reset on the first pass. There should be extra tests to cover this bug too. > Provide a check to see if the last recovery scan "cleaned" the store. > ---------------------------------------------------------------------- > > Key: JBTM-3017 > URL: https://issues.jboss.org/browse/JBTM-3017 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Recovery, Tooling > Affects Versions: 5.8.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > There are some recovery manager use cases where the user needs to know that the log store is empty and that all orphans have been detected (for example it is possible that some resource managers were not available during the last scan). > This feature would be particularly useful when running on OpenShift in order to determine when it is safe scale down and reclaim the space used by a pod. -- This message was sent by Atlassian JIRA (v7.5.0#75005)