From issues at jboss.org Wed Jul 4 07:28:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 4 Jul 2018 07:28: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 ] Tom Jenkinson resolved JBTM-3017. --------------------------------- Fix Version/s: 5.5.32.Final Resolution: Done > 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.5.32.Final, 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 Jul 4 07:29:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 4 Jul 2018 07:29:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2928) Provide WS-AT Integration with .NET In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2928: -------------------------------- Fix Version/s: 5.5.32.Final > Provide WS-AT Integration with .NET > ----------------------------------- > > Key: JBTM-2928 > URL: https://issues.jboss.org/browse/JBTM-2928 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: XTS > Affects Versions: 5.7.2.Final > Reporter: J?rg B?sner > Fix For: 5.8.0.Final, 5.5.32.Final > > > Provide WS-AT integration for .NET -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jul 4 10:56:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 4 Jul 2018 10:56: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: ---------------------------------- Attachment: JBTM-3034-xarm-to-query-cmrrm.diff > 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 > Attachments: JBTM-3034-xarm-to-query-cmrrm.diff > > > 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 Jul 4 11:02:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 4 Jul 2018 11:02: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=13601264#comment-13601264 ] Ondra Chaloupka commented on JBTM-3034: --------------------------------------- Based on the discussion on the forum [https://developer.jboss.org/message/983892|https://developer.jboss.org/message/983892] there should not be the issue of {{XATerminator}} which would not be capable to commit the inflow transaction. By reverting back the change introduced by JBTM-2734 at XARecoveryModule#getNewXAResource https://github.com/jbosstm/narayana/pull/1059/files#diff-8487f43e773b3321c5396187b559bfffL261 we should not cause any functionality error (possible a warning log message nonxaresourcerecovery could be shown in some tooling corner cases). I have tried to use different approach, than the reverting one which will be published in PR, which is checking in XARecoveryModule if CMRRecoveryModule knows about the XAResource. It's presented in branch https://github.com/ochaloup/narayana/tree/JBTM-3034-cmr-failures and the changeset is uploaded here in diff at https://issues.jboss.org/secure/attachment/12437356/JBTM-3034-xarm-to-query-cmrrm.diff > 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 > Attachments: JBTM-3034-xarm-to-query-cmrrm.diff > > > 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 Jul 4 11:06:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 4 Jul 2018 11:06: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: ---------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/1343 > 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 > Attachments: JBTM-3034-xarm-to-query-cmrrm.diff > > > 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 Jul 4 11:07:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 4 Jul 2018 11:07: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: ---------------------------------- Status: Pull Request Sent (was: Open) > 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 > Attachments: JBTM-3034-xarm-to-query-cmrrm.diff > > > 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 Thu Jul 5 04:59:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 04:59: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: [ https://issues.jboss.org/browse/JBTM-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13601399#comment-13601399 ] Tom Jenkinson commented on JBTM-3037: ------------------------------------- I am not sure how this didn't link up with GitHub but the commit is here: https://github.com/jbosstm/narayana/commit/3c4b7c08f310eadb7cc87f9dfb1223c7b048a6f5 > 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 Thu Jul 5 04:59:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 04:59: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: [ https://issues.jboss.org/browse/JBTM-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-3037. --------------------------------- Resolution: Done > 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 Thu Jul 5 05:00:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:00: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 ] Tom Jenkinson updated JBTM-3038: -------------------------------- Issue Type: Task (was: Bug) > 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: Task > 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 Thu Jul 5 05:00:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:00: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:all-tabpanel ] Tom Jenkinson updated JBTM-3031: -------------------------------- Fix Version/s: 5.next > 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 > Fix For: 5.next > > > 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 Thu Jul 5 05:01:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:01: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 ] Tom Jenkinson updated JBTM-2982: -------------------------------- Fix Version/s: 5.next > 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 > Fix For: 5.next > > > 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 Thu Jul 5 05:01:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:01:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3027) Failing LRA quickstarts as Narayana still reports dependency at lra annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3027: -------------------------------- Fix Version/s: 5.next > Failing LRA quickstarts as Narayana still reports dependency at lra annotations > ------------------------------------------------------------------------------- > > Key: JBTM-3027 > URL: https://issues.jboss.org/browse/JBTM-3027 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.8.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.next > > > LRA quickstarts are failing ({{/home/ochaloup/Transactions/quickstart-jbosstm/rts/lra}}) because the fraction which is created from the {{lra-filters}} injects not only eclipse lra annotations but the narayana:lra-annotations dependency too. > There is fail on the injections with errors like > {code} > 2018-05-23 16:56:41,684 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."lra-test.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."lra-test.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type LRAClient with qualifiers @Default > at injection point [BackedAnnotatedField] @Inject private io.narayana.rts.lra.demo.flight.FlightService.lraClient > at io.narayana.rts.lra.demo.flight.FlightService.lraClient(FlightService.java:0) > at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359) > at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281) > at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134) > at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155) > at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:02:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:02:01 -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 ] Tom Jenkinson updated JBTM-2880: -------------------------------- Fix Version/s: 5.next (was: 5.later) > 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.next > > > 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 Thu Jul 5 05:02:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:02:01 -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 ] Tom Jenkinson updated JBTM-2880: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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.next > > > 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 Thu Jul 5 05:02:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:02:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3025) Xid created for JTS imported transaction set up wrong node name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3025: -------------------------------- Fix Version/s: 5.next > Xid created for JTS imported transaction set up wrong node name > --------------------------------------------------------------- > > Key: JBTM-3025 > URL: https://issues.jboss.org/browse/JBTM-3025 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.8.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > Fix For: 5.next > > > For JTS being able to handle multiple inflow transactions there was made fix at https://issues.jboss.org/browse/JBTM-2893. Unfortunately the fix introduces issue where node name of the newly created Xid is incorrect. Even we have imported transaction which should be considered as subordinate we set up automatically node name equal to the current Narayana node. > I expect, the correct behavior should be to let the node name being the same as it was provided by import transaction call. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:03:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2978) Compensation should not be considered done in case of network error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2978: -------------------------------- Fix Version/s: 5.next > Compensation should not be considered done in case of network error > ------------------------------------------------------------------- > > Key: JBTM-2978 > URL: https://issues.jboss.org/browse/JBTM-2978 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Nicola Ferraro > Assignee: Michael Musgrove > Fix For: 5.next > > > In case of network error on the call to "/compensate" made by the coordinator to the participant, the LRA is considered compensated, hence the compensate action is not retried again. This is not the expected behavior. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:03:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2977) Participants should not be told to compensate after completion In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2977: -------------------------------- Fix Version/s: 5.next > Participants should not be told to compensate after completion > -------------------------------------------------------------- > > Key: JBTM-2977 > URL: https://issues.jboss.org/browse/JBTM-2977 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Nicola Ferraro > Assignee: Michael Musgrove > Fix For: 5.next > > > When a LRA is closed the coordinator behaves incorrectly if a participant is slow to respond. > While the call to "/complete" is still ongoing, the coordinator (recovery module) may issue a second call to "/compensate", making it impossible for the participant to determine when a LRA is really closed. > The LRA coordinator must choose a single outcome for the LRA and be consistent with that (retrying until all participants are in status complete/failedtocomplete in this case). > A second minor problem is that the call to "/close" is synchronous, and the caller is kept attached forever if the participant does not respond to "/complete". It would be better to establish a timeout and return a "Completing" status if not all participant are done in time. > I attach few simple steps to reproduce it with shell commands. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:05:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2262) ORB JTS classes not added to classpath in setup script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2262: -------------------------------- Fix Version/s: 5.0.4 > ORB JTS classes not added to classpath in setup script > ------------------------------------------------------ > > Key: JBTM-2262 > URL: https://issues.jboss.org/browse/JBTM-2262 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Tom Jenkinson > Fix For: 5.0.4 > > > Tried using the setup script which does create/augment the CLASSPATH. But it doesn't add the jts-jacorb.jar (or equivalent) for some reason. So when trying to run the transaction manager (using the startup script) it fails. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:05:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2262) ORB JTS classes not added to classpath in setup script In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2262. ------------------------------- > ORB JTS classes not added to classpath in setup script > ------------------------------------------------------ > > Key: JBTM-2262 > URL: https://issues.jboss.org/browse/JBTM-2262 > Project: JBoss Transaction Manager > Issue Type: Task > Components: JTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Tom Jenkinson > Fix For: 5.0.4 > > > Tried using the setup script which does create/augment the CLASSPATH. But it doesn't add the jts-jacorb.jar (or equivalent) for some reason. So when trying to run the transaction manager (using the startup script) it fails. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:06:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2281) Merge the documentation manuals together In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2281: -------------------------------- Fix Version/s: 5.2.0 > Merge the documentation manuals together > ---------------------------------------- > > Key: JBTM-2281 > URL: https://issues.jboss.org/browse/JBTM-2281 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 5.2.0 > > > The documentation for our project is available here: > Narayana Documentation 5.0.2.Final - JBoss Community > > As you can see it consists of several downloads including multiple books, links to various JavaDocs and some IDL files. Personally I think it might be easier to locate documentation entries if there is a single document to consult and a single JavaDoc link. I consulted our users whether anyone would object to us producing a single document and single JavaDoc set and received no objection. I am also thinking of no longer publishing the IDL as separate files as these are always tagged and available in our repo. > One way or another we need to make it clear in the docs what is in product and what is in project. Its not quite so important for our community users to know this but when translating docs into product manuals it is crucial. Currently this is done because everything under https://github.com/jbosstm/documentation/tree/master/docs is product related and things one level up are various community projects. An obvious way to merge the docs is merge everything under docs and then everything under ../* except docs - i.e. 2 manuals -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:06:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2281) Merge the documentation manuals together In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2281. ------------------------------- > Merge the documentation manuals together > ---------------------------------------- > > Key: JBTM-2281 > URL: https://issues.jboss.org/browse/JBTM-2281 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Gytis Trikleris > Fix For: 5.2.0 > > > The documentation for our project is available here: > Narayana Documentation 5.0.2.Final - JBoss Community > > As you can see it consists of several downloads including multiple books, links to various JavaDocs and some IDL files. Personally I think it might be easier to locate documentation entries if there is a single document to consult and a single JavaDoc link. I consulted our users whether anyone would object to us producing a single document and single JavaDoc set and received no objection. I am also thinking of no longer publishing the IDL as separate files as these are always tagged and available in our repo. > One way or another we need to make it clear in the docs what is in product and what is in project. Its not quite so important for our community users to know this but when translating docs into product manuals it is crucial. Currently this is done because everything under https://github.com/jbosstm/documentation/tree/master/docs is product related and things one level up are various community projects. An obvious way to merge the docs is merge everything under docs and then everything under ../* except docs - i.e. 2 manuals -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:07:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2304) Cannot compile TestModule.idl using IBM stub compiler (JDK8) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2304: -------------------------------- Fix Version/s: 5.2.0 > Cannot compile TestModule.idl using IBM stub compiler (JDK8) > ------------------------------------------------------------ > > Key: JBTM-2304 > URL: https://issues.jboss.org/browse/JBTM-2304 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System, JTS > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.2.0 > > > {quote} > org.jboss.jbossts.qa.idl.compile.init: > [idl-compiler] Parsing... > [idl-compiler] Processing for ibmorb '/home/hudson/workspace/narayana-ibm-jdk/qa/dist/../../ArjunaJTS/idl/src/test/idl/TestModule.idl' > BUILD FAILED > /home/hudson/workspace/narayana-ibm-jdk/qa/build.xml:123: The following error occurred while executing this line: > /home/hudson/workspace/narayana-ibm-jdk/qa/tests/build-jts.xml:229: Failed to compile '/home/hudson/workspace/narayana-ibm-jdk/qa/dist/../../ArjunaJTS/idl/src/test/idl/TestModule.idl' file > Total time: 2 seconds > qa build failed > {quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:07:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2304) Cannot compile TestModule.idl using IBM stub compiler (JDK8) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2304. ------------------------------- > Cannot compile TestModule.idl using IBM stub compiler (JDK8) > ------------------------------------------------------------ > > Key: JBTM-2304 > URL: https://issues.jboss.org/browse/JBTM-2304 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System, JTS > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.2.0 > > > {quote} > org.jboss.jbossts.qa.idl.compile.init: > [idl-compiler] Parsing... > [idl-compiler] Processing for ibmorb '/home/hudson/workspace/narayana-ibm-jdk/qa/dist/../../ArjunaJTS/idl/src/test/idl/TestModule.idl' > BUILD FAILED > /home/hudson/workspace/narayana-ibm-jdk/qa/build.xml:123: The following error occurred while executing this line: > /home/hudson/workspace/narayana-ibm-jdk/qa/tests/build-jts.xml:229: Failed to compile '/home/hudson/workspace/narayana-ibm-jdk/qa/dist/../../ArjunaJTS/idl/src/test/idl/TestModule.idl' file > Total time: 2 seconds > qa build failed > {quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:07:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2303) Cannot create jacoco report In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2303: -------------------------------- Fix Version/s: 5.0.4 > Cannot create jacoco report > --------------------------- > > Key: JBTM-2303 > URL: https://issues.jboss.org/browse/JBTM-2303 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.0.4 > > > {quote} > [jacoco:coverage] Enhancing junit with coverage > [junit] Running org.jboss.jbossts.qa.junit.testgroup.TestGroup_jdbcresources02_pgsql_jndi > [junit] Tests run: 30, Failures: 0, Errors: 0, Time elapsed: 412.658 sec > ci-tests: > BUILD SUCCESSFUL > Total time: 447 minutes 53 seconds > generating test coverage report > Buildfile: /home/hudson/workspace/narayana-codeCoverage/qa/run-tests.xml > jacoco-report: > [jacoco:report] Loading execution data file /home/hudson/workspace/narayana-codeCoverage/qa/testoutput/jacoco-qa.exec > BUILD FAILED > /home/hudson/workspace/narayana-codeCoverage/qa/run-tests.xml:544: Error while creating report > {quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:08:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2303) Cannot create jacoco report In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2303. ------------------------------- > Cannot create jacoco report > --------------------------- > > Key: JBTM-2303 > URL: https://issues.jboss.org/browse/JBTM-2303 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.0.4 > > > {quote} > [jacoco:coverage] Enhancing junit with coverage > [junit] Running org.jboss.jbossts.qa.junit.testgroup.TestGroup_jdbcresources02_pgsql_jndi > [junit] Tests run: 30, Failures: 0, Errors: 0, Time elapsed: 412.658 sec > ci-tests: > BUILD SUCCESSFUL > Total time: 447 minutes 53 seconds > generating test coverage report > Buildfile: /home/hudson/workspace/narayana-codeCoverage/qa/run-tests.xml > jacoco-report: > [jacoco:report] Loading execution data file /home/hudson/workspace/narayana-codeCoverage/qa/testoutput/jacoco-qa.exec > BUILD FAILED > /home/hudson/workspace/narayana-codeCoverage/qa/run-tests.xml:544: Error while creating report > {quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:08:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:08:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2314) JTS Jacoco report missing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2314. ------------------------------- > JTS Jacoco report missing > ------------------------- > > Key: JBTM-2314 > URL: https://issues.jboss.org/browse/JBTM-2314 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > JTS Jacoco report is for jacorb is missing. > Also check for any others that might be missing - the ones our CI job is currently producing are: > ../STM/target/site/jacoco-ut/jacoco.csv > ../tools/target/site/jacoco-ut/jacoco.csv > ../ArjunaCore/txoj/target/site/jacoco-ut/jacoco.csv > ../ArjunaCore/arjuna/target/site/jacoco-ut/jacoco.csv > ../rts/at/integration/target/site/jacoco-ut/jacoco.csv > ../rts/at/tx/target/site/jacoco-ut/jacoco.csv > ../rts/at/bridge/target/site/jacoco-ut/jacoco.csv > ../ArjunaJTA/jta/target/site/jacoco-ut/jacoco.csv > ../ArjunaJTA/cdi/target/site/jacoco-ut/jacoco.csv > ../txbridge/target/site/jacoco-ut/jacoco.csv > ../common/target/site/jacoco-ut/jacoco.csv > ../compensations/target/site/jacoco-ut/jacoco.csv -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:09:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:09:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2332) resolve_initial_references on JDK ORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2332: -------------------------------- Fix Version/s: 5.1.0 > resolve_initial_references on JDK ORB > ------------------------------------- > > Key: JBTM-2332 > URL: https://issues.jboss.org/browse/JBTM-2332 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Affects Versions: 5.0.4 > Reporter: Mark Little > Assignee: Michael Musgrove > Fix For: 5.1.0 > > > Check how the JDK ORB uses resolve_initial_references and that it is tied into the ORB Portability layer. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:09:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:09:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2332) resolve_initial_references on JDK ORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2332. ------------------------------- > resolve_initial_references on JDK ORB > ------------------------------------- > > Key: JBTM-2332 > URL: https://issues.jboss.org/browse/JBTM-2332 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Affects Versions: 5.0.4 > Reporter: Mark Little > Assignee: Michael Musgrove > Fix For: 5.1.0 > > > Check how the JDK ORB uses resolve_initial_references and that it is tied into the ORB Portability layer. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:09:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:09:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2348) No CI job for testing git pull requests against the benchmark perf repo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2348: -------------------------------- Issue Type: Task (was: Feature Request) > No CI job for testing git pull requests against the benchmark perf repo > ----------------------------------------------------------------------- > > Key: JBTM-2348 > URL: https://issues.jboss.org/browse/JBTM-2348 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > There is no CI job for testing PRs against the benchmarks in the performance repo https://github.com/jbosstm/performance/narayana repo -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:09:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:09:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2348) No CI job for testing git pull requests against the benchmark perf repo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2348. ------------------------------- > No CI job for testing git pull requests against the benchmark perf repo > ----------------------------------------------------------------------- > > Key: JBTM-2348 > URL: https://issues.jboss.org/browse/JBTM-2348 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Michael Musgrove > Assignee: Michael Musgrove > > There is no CI job for testing PRs against the benchmarks in the performance repo https://github.com/jbosstm/performance/narayana repo -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:10:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:10:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2297) Store docker image for service(s) in JBoss repo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2297. ------------------------------- > Store docker image for service(s) in JBoss repo > ----------------------------------------------- > > Key: JBTM-2297 > URL: https://issues.jboss.org/browse/JBTM-2297 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Cloud, JTS, REST, XTS > Affects Versions: 5.0.3 > Reporter: Mark Little > Assignee: Gytis Trikleris > > We have a repo for JBoss project docker images. Store our final version (not POC version I created) there. Also see if this also suggests a way of distributing and storing the docker file to create it/them. I'm assuming we don't need to store this information within the Narayana repo, but perhaps we do and in which case we'll probably need a docker directory. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:10:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:10:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2431) Arquillian failures due to version mismatches In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2431: -------------------------------- Fix Version/s: 5.2.0 > Arquillian failures due to version mismatches > --------------------------------------------- > > Key: JBTM-2431 > URL: https://issues.jboss.org/browse/JBTM-2431 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.2.0 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > We were getting failures with the current versions of Arquillian WildFly Managed Container Adapter and Arquillian Core when using the current wildfly master branch. This was because we were using incompatible versions which I have just fixed (commit dab8736): > bq. Arquillian WildFly Managed Container Adapter 1.0.0.Alpha5 is built with Arquillian Core - 1.1.7.Final > But the osgi tests need to run with karaf and the most recent arquillian osgi karaf container was built with Arquillian Core 1.1.2.Final. So I will fix it by updating the osgi pom to use that version of arquillian core: > bq. 2.1.0.CR15 is built with Arquillian Core - 1.1.2.Final and ShrinkWrap - 1.1.2 > The version compatibility details are: [WildFly Managed Container Adapter | http://arquillian.org/modules/wildfly-arquillian-wildfly-managed-container-adapter/] and [arquillian osgi karaf container |http://arquillian.org/modules/arquillian-osgi-karaf-embedded-container-adapter] -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:10:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:10:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2431) Arquillian failures due to version mismatches In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2431. ------------------------------- > Arquillian failures due to version mismatches > --------------------------------------------- > > Key: JBTM-2431 > URL: https://issues.jboss.org/browse/JBTM-2431 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.2.0 > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > We were getting failures with the current versions of Arquillian WildFly Managed Container Adapter and Arquillian Core when using the current wildfly master branch. This was because we were using incompatible versions which I have just fixed (commit dab8736): > bq. Arquillian WildFly Managed Container Adapter 1.0.0.Alpha5 is built with Arquillian Core - 1.1.7.Final > But the osgi tests need to run with karaf and the most recent arquillian osgi karaf container was built with Arquillian Core 1.1.2.Final. So I will fix it by updating the osgi pom to use that version of arquillian core: > bq. 2.1.0.CR15 is built with Arquillian Core - 1.1.2.Final and ShrinkWrap - 1.1.2 > The version compatibility details are: [WildFly Managed Container Adapter | http://arquillian.org/modules/wildfly-arquillian-wildfly-managed-container-adapter/] and [arquillian osgi karaf container |http://arquillian.org/modules/arquillian-osgi-karaf-embedded-container-adapter] -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:12:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:12: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 ] Tom Jenkinson updated JBTM-2988: -------------------------------- Fix Version/s: 5.8.0.Final > 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 > Fix For: 5.8.0.Final > > > 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 Thu Jul 5 05:12:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:12: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 ] Tom Jenkinson closed JBTM-2988. ------------------------------- > 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 > Fix For: 5.8.0.Final > > > 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 Thu Jul 5 05:14:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:14: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 ] Tom Jenkinson updated JBTM-2621: -------------------------------- Fix Version/s: 5.3.4.Final > 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 > Fix For: 5.3.4.Final > > > 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 Thu Jul 5 05:14:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:14:01 -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 ] Tom Jenkinson closed JBTM-2621. ------------------------------- > 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 > Fix For: 5.3.4.Final > > > 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 Thu Jul 5 05:15:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:15:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2979) Timeout leaves LRA active and able to complete In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2979: -------------------------------- Fix Version/s: 5.next > Timeout leaves LRA active and able to complete > ---------------------------------------------- > > Key: JBTM-2979 > URL: https://issues.jboss.org/browse/JBTM-2979 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Nicola Ferraro > Assignee: Michael Musgrove > Fix For: 5.next > > > If a participant declares a timeout, the coordinator calls its "/compensate" endpoint when the timeout expires. But the LRA remains active and it may be possibly closed, leading to a second call to "/complete" on the participant, even if he has already compensated. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:15:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:15:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3026) LRA tests cause issues when being built on machines/jdk preferring IPv6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3026: -------------------------------- Fix Version/s: 5.next > LRA tests cause issues when being built on machines/jdk preferring IPv6 > ----------------------------------------------------------------------- > > Key: JBTM-3026 > URL: https://issues.jboss.org/browse/JBTM-3026 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.8.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.next > > > There is issue of running LRA tests which use {{org.honton.chas:process-exec-maven-plugin}} to start wildfly swarm container because Arquillian plugin is capable to start only one swarm container. That way the coordinator is started in {{pre-integration-test}} phase with that plugin. There is an issue when system prefers IPv6 then the port is not capable to be bound. > see {{rts/lra/lra-test/target//failsafe-reports/lra-coordinator-swarm-startup.log}} > {code} > [0m[0m2018-05-23 12:07:28,018 INFO??[org.xnio.nio] (MSC service thread 1-8) XNIO NIO Implementation Version 3.4.3.Final > [0m[0m2018-05-23 12:07:28,062 INFO??[org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0012: Started server default-server. > [0m[31m2018-05-23 12:07:28,099 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153) > ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > ??at java.lang.Thread.run(Thread.java:748) > Caused by: java.net.SocketException: Protocol family unavailable > ??at sun.nio.ch.Net.bind0(Native Method) > ??at sun.nio.ch.Net.bind(Net.java:433) > ??at sun.nio.ch.Net.bind(Net.java:425) > ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171) > ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245) > ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126) > ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142) > ??... 5 more > [0m[31m2018-05-23 12:07:28,126 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ????("subsystem" => "undertow"), > ????("server" => "default-server"), > ????("http-listener" => "default") > ]) - failure description: { > ????"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.default" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > ????Caused by: java.net.SocketException: Protocol family unavailable"}, > ????"WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.listener.default"], > ????"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > [0m[0m2018-05-23 12:07:28,145 INFO??[org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0186:?? Services which failed to start:??????service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > [0m[31m2018-05-23 12:07:28,180 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started (with errors) in 916ms - Started 85 of 96 services (1 services failed or missing dependencies, 18 services are lazy, passive or on-demand) > [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) java.lang.reflect.InvocationTargetException > [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at java.lang.reflect.Method.invoke(Method.java:498) > [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.MainInvoker.invoke(MainInvoker.java:39) > [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.run(Main.java:133) > [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.main(Main.java:86) > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) Caused by: java.lang.RuntimeException: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.spi.api.ClassLoading.withTCCL(ClassLoading.java:45) > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.container.runtime.ServerBootstrapImpl.bootstrap(ServerBootstrapImpl.java:114) > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.start(Swarm.java:372) > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.main(Swarm.java:628) > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??... 7 more > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) Caused by: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153) > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.lang.Thread.run(Thread.java:748) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) Caused by: java.net.SocketException: Protocol family unavailable > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind0(Native Method) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:433) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:425) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126) > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142) > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??... 5 more > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) Exception in thread "main" java.lang.reflect.InvocationTargetException > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at java.lang.reflect.Method.invoke(Method.java:498) > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.MainInvoker.invoke(MainInvoker.java:39) > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.run(Main.java:133) > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.main(Main.java:86) > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) Caused by: java.lang.RuntimeException: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.spi.api.ClassLoading.withTCCL(ClassLoading.java:45) > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.container.runtime.ServerBootstrapImpl.bootstrap(ServerBootstrapImpl.java:114) > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.start(Swarm.java:372) > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.main(Swarm.java:628) > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??... 7 more > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) Caused by: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153) > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at java.lang.Thread.run(Thread.java:748) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) Caused by: java.net.SocketException: Protocol family unavailable > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind0(Native Method) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:433) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:425) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126) > [0m[31m2018-05-23 12:07:28,196 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142) > [0m[31m2018-05-23 12:07:28,196 ERROR [stderr] (main) ??... 5 more > [0m[0m2018-05-23 12:07:55,607 INFO??[org.wildfly.swarm] (Thread-3) WFSWARM0027: Shutdown requested > [0m[0m2018-05-23 12:07:55,608 INFO??[org.jboss.as.server] (Thread-4) WFLYSRV0220: Server shutdown has been requested via an OS signal > [0m[0m2018-05-23 12:07:55,612 INFO??[org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.4.11.Final stopping > [0m[0m2018-05-23 12:07:55,621 INFO??[org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 9ms > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:15:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:15:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2958) Wrong format of the Link header on joining LRA by participant should return error to the participant In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2958: -------------------------------- Fix Version/s: 5.8.2.Final > Wrong format of the Link header on joining LRA by participant should return error to the participant > ---------------------------------------------------------------------------------------------------- > > Key: JBTM-2958 > URL: https://issues.jboss.org/browse/JBTM-2958 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Fix For: 5.8.2.Final > > > If there is a participant joining a started LRA which uses wrong format of {{Link}} header then {{NullPointer}} is logged to the swarm server log. But client gets status {{OK}}. > Client should be informed that enlistment failed and there should not be nullpointer in the log. > NullPointer > {code} > INFO [io.narayana.lra] (default task-4) Cannot extract compensator from link'http://localhost': java.lang.IllegalArgumentException: RESTEASY003960: Unable to parse Link header. No end to parameter: http://localhost > at org.jboss.resteasy.plugins.delegates.LinkDelegate$Parser.parseAttribute(LinkDelegate.java:112) > at org.jboss.resteasy.plugins.delegates.LinkDelegate$Parser.parse(LinkDelegate.java:63) > at org.jboss.resteasy.plugins.delegates.LinkDelegate.fromString(LinkDelegate.java:160) > at org.jboss.resteasy.plugins.delegates.LinkDelegate.fromString(LinkDelegate.java:23) > at org.jboss.resteasy.specimpl.LinkImpl.valueOf(LinkImpl.java:31) > at org.jboss.resteasy.specimpl.LinkBuilderImpl.link(LinkBuilderImpl.java:34) > at javax.ws.rs.core.Link.valueOf(Link.java:173) > at io.narayana.lra.coordinator.domain.model.LRARecord.extractCompensator(LRARecord.java:150) > at io.narayana.lra.coordinator.domain.model.Transaction.findLRAParticipant(Transaction.java:498) > at io.narayana.lra.coordinator.domain.model.Transaction.enlistParticipant(Transaction.java:428) > at io.narayana.lra.coordinator.domain.service.LRAService.joinLRA(LRAService.java:268) > at io.narayana.lra.coordinator.domain.service.LRAService$Proxy$_$$_WeldClientProxy.joinLRA(Unknown Source) > at io.narayana.lra.coordinator.api.Coordinator.joinLRA(Coordinator.java:468) > at io.narayana.lra.coordinator.api.Coordinator.joinLRAViaBody(Coordinator.java:406) > at io.narayana.lra.coordinator.api.Coordinator$Proxy$_$$_WeldClientProxy.joinLRAViaBody(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.swarm.generated.FaviconErrorHandler.handleRequest(FaviconErrorHandler.java:62) > at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > {code} > The ok return code: > {code} > curl -i -X PUT -H "Link: http://localhost" http://localhost:8080/lra-coordinator/0_ffff0a000007_-39bdc3dc_5a098390_d > HTTP/1.1 200 OK > Connection: keep-alive > Long-Running-Action-Recovery: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8080%2Flra-coordinator%2F0_ffff0a000007_-39bdc3dc_5a098390_d/0_ffff0a000007_-39bdc3dc_5a098390_11 > Location: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8080%2Flra-coordinator%2F0_ffff0a000007_-39bdc3dc_5a098390_d/0_ffff0a000007_-39bdc3dc_5a098390_11 > Content-Type: application/json > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:15:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:15:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2958) Wrong format of the Link header on joining LRA by participant should return error to the participant In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2958. ------------------------------- > Wrong format of the Link header on joining LRA by participant should return error to the participant > ---------------------------------------------------------------------------------------------------- > > Key: JBTM-2958 > URL: https://issues.jboss.org/browse/JBTM-2958 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > Fix For: 5.8.2.Final > > > If there is a participant joining a started LRA which uses wrong format of {{Link}} header then {{NullPointer}} is logged to the swarm server log. But client gets status {{OK}}. > Client should be informed that enlistment failed and there should not be nullpointer in the log. > NullPointer > {code} > INFO [io.narayana.lra] (default task-4) Cannot extract compensator from link'http://localhost': java.lang.IllegalArgumentException: RESTEASY003960: Unable to parse Link header. No end to parameter: http://localhost > at org.jboss.resteasy.plugins.delegates.LinkDelegate$Parser.parseAttribute(LinkDelegate.java:112) > at org.jboss.resteasy.plugins.delegates.LinkDelegate$Parser.parse(LinkDelegate.java:63) > at org.jboss.resteasy.plugins.delegates.LinkDelegate.fromString(LinkDelegate.java:160) > at org.jboss.resteasy.plugins.delegates.LinkDelegate.fromString(LinkDelegate.java:23) > at org.jboss.resteasy.specimpl.LinkImpl.valueOf(LinkImpl.java:31) > at org.jboss.resteasy.specimpl.LinkBuilderImpl.link(LinkBuilderImpl.java:34) > at javax.ws.rs.core.Link.valueOf(Link.java:173) > at io.narayana.lra.coordinator.domain.model.LRARecord.extractCompensator(LRARecord.java:150) > at io.narayana.lra.coordinator.domain.model.Transaction.findLRAParticipant(Transaction.java:498) > at io.narayana.lra.coordinator.domain.model.Transaction.enlistParticipant(Transaction.java:428) > at io.narayana.lra.coordinator.domain.service.LRAService.joinLRA(LRAService.java:268) > at io.narayana.lra.coordinator.domain.service.LRAService$Proxy$_$$_WeldClientProxy.joinLRA(Unknown Source) > at io.narayana.lra.coordinator.api.Coordinator.joinLRA(Coordinator.java:468) > at io.narayana.lra.coordinator.api.Coordinator.joinLRAViaBody(Coordinator.java:406) > at io.narayana.lra.coordinator.api.Coordinator$Proxy$_$$_WeldClientProxy.joinLRAViaBody(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.swarm.generated.FaviconErrorHandler.handleRequest(FaviconErrorHandler.java:62) > at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94) > at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44) > at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > at io.undertow.server.Connectors.executeRootHandler(Connectors.java:211) > at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > {code} > The ok return code: > {code} > curl -i -X PUT -H "Link: http://localhost" http://localhost:8080/lra-coordinator/0_ffff0a000007_-39bdc3dc_5a098390_d > HTTP/1.1 200 OK > Connection: keep-alive > Long-Running-Action-Recovery: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8080%2Flra-coordinator%2F0_ffff0a000007_-39bdc3dc_5a098390_d/0_ffff0a000007_-39bdc3dc_5a098390_11 > Location: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8080%2Flra-coordinator%2F0_ffff0a000007_-39bdc3dc_5a098390_d/0_ffff0a000007_-39bdc3dc_5a098390_11 > Content-Type: application/json > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:16:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:16:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3021) Running afterCompletion from reaper thread can get ConcurrentModificationException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-3021. ------------------------------- > Running afterCompletion from reaper thread can get ConcurrentModificationException > ---------------------------------------------------------------------------------- > > Key: JBTM-3021 > URL: https://issues.jboss.org/browse/JBTM-3021 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Amos Feng > Assignee: Tom Jenkinson > Fix For: 5.8.2.Final > > > The way the locking works _syncLock and _synchs are used at different times and so it can be that _syncs is not locked and the .iterator() .next() might get CoModEx -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:16:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:16:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3021) Running afterCompletion from reaper thread can get ConcurrentModificationException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3021: -------------------------------- Fix Version/s: 5.8.2.Final > Running afterCompletion from reaper thread can get ConcurrentModificationException > ---------------------------------------------------------------------------------- > > Key: JBTM-3021 > URL: https://issues.jboss.org/browse/JBTM-3021 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Reporter: Amos Feng > Assignee: Tom Jenkinson > Fix For: 5.8.2.Final > > > The way the locking works _syncLock and _synchs are used at different times and so it can be that _syncs is not locked and the .iterator() .next() might get CoModEx -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:16:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:16:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3011) Uploading lra coordinator docker image should be part of the narayana release process In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3011: -------------------------------- Fix Version/s: 5.8.2.Final > Uploading lra coordinator docker image should be part of the narayana release process > ------------------------------------------------------------------------------------- > > Key: JBTM-3011 > URL: https://issues.jboss.org/browse/JBTM-3011 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Build System, LRA > Affects Versions: 5.8.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.8.2.Final > > > when narayana release is run we should consider pushing the lra docker image to the docker hub at the https://hub.docker.com/r/jbosstm/lra-coordinator/ -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:16:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:16:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3011) Uploading lra coordinator docker image should be part of the narayana release process In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-3011. ------------------------------- > Uploading lra coordinator docker image should be part of the narayana release process > ------------------------------------------------------------------------------------- > > Key: JBTM-3011 > URL: https://issues.jboss.org/browse/JBTM-3011 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Build System, LRA > Affects Versions: 5.8.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.8.2.Final > > > when narayana release is run we should consider pushing the lra docker image to the docker hub at the https://hub.docker.com/r/jbosstm/lra-coordinator/ -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:17:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:17:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3003) standalone-xts.xml is not found in WS-AT performance tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3003: -------------------------------- Fix Version/s: 5.8.1.Final > standalone-xts.xml is not found in WS-AT performance tests > ---------------------------------------------------------- > > Key: JBTM-3003 > URL: https://issues.jboss.org/browse/JBTM-3003 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing, XTS > Reporter: Tom Jenkinson > Assignee: Ondra Chaloupka > Fix For: 5.8.1.Final > > > [INFO] ------------------------------------------------------------------------ > [INFO] Building ws-at 1.0-SNAPSHOT > [INFO] ------------------------------------------------------------------------ > [INFO] > [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ws-at --- > [INFO] > [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ ws-at --- > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] skip non existing resourceDirectory /home/hudson/workspace/narayana-performance/comparison/ws-at/src/main/resources > [INFO] > [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ ws-at --- > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 8 source files to /home/hudson/workspace/narayana-performance/comparison/ws-at/target/classes > [INFO] > [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ ws-at --- > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] Copying 2 resources > [INFO] > [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ ws-at --- > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 1 source file to /home/hudson/workspace/narayana-performance/comparison/ws-at/target/test-classes > [INFO] > [INFO] --- maven-antrun-plugin:1.7:run (default) @ ws-at --- > [INFO] Executing tasks > main: > [copy] Copying 12826 files to /home/hudson/workspace/narayana-performance/comparison/ws-at/target/server1 > [copy] Copied 4874 empty directories to 143 empty directories under /home/hudson/workspace/narayana-performance/comparison/ws-at/target/server1 > [copy] Copying 25652 files to /home/hudson/workspace/narayana-performance/comparison/ws-at/target/server2 > [copy] Copied 9748 empty directories to 286 empty directories under /home/hudson/workspace/narayana-performance/comparison/ws-at/target/server2 > [copy] Copying 51304 files to /home/hudson/workspace/narayana-performance/comparison/ws-at/target/server3 > [copy] Copied 19496 empty directories to 572 empty directories under /home/hudson/workspace/narayana-performance/comparison/ws-at/target/server3 > [INFO] ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] comparison-parent .................................. SUCCESS [ 0.189 s] > [INFO] common ............................................. SUCCESS [ 1.305 s] > [INFO] ws-at .............................................. FAILURE [ 30.599 s] > [INFO] rest-at ............................................ SKIPPED > [INFO] jts ................................................ SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 32.244 s > [INFO] Finished at: 2018-03-25T00:07:53+00:00 > [INFO] Final Memory: 62M/680M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run (default) on project ws-at: An Ant BuildException has occured: Warning: Could not find file /home/hudson/workspace/narayana-performance/docs/examples/configs/standalone-xts.xml to copy. > [ERROR] around Ant part ...... @ 13:232 in /home/hudson/workspace/narayana-performance/comparison/ws-at/target/antrun/build-main.xml -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:17:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:17:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3003) standalone-xts.xml is not found in WS-AT performance tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-3003. ------------------------------- > standalone-xts.xml is not found in WS-AT performance tests > ---------------------------------------------------------- > > Key: JBTM-3003 > URL: https://issues.jboss.org/browse/JBTM-3003 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing, XTS > Reporter: Tom Jenkinson > Assignee: Ondra Chaloupka > Fix For: 5.8.1.Final > > > [INFO] ------------------------------------------------------------------------ > [INFO] Building ws-at 1.0-SNAPSHOT > [INFO] ------------------------------------------------------------------------ > [INFO] > [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ws-at --- > [INFO] > [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ ws-at --- > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] skip non existing resourceDirectory /home/hudson/workspace/narayana-performance/comparison/ws-at/src/main/resources > [INFO] > [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ ws-at --- > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 8 source files to /home/hudson/workspace/narayana-performance/comparison/ws-at/target/classes > [INFO] > [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ ws-at --- > [INFO] Using 'UTF-8' encoding to copy filtered resources. > [INFO] Copying 2 resources > [INFO] > [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ ws-at --- > [INFO] Changes detected - recompiling the module! > [INFO] Compiling 1 source file to /home/hudson/workspace/narayana-performance/comparison/ws-at/target/test-classes > [INFO] > [INFO] --- maven-antrun-plugin:1.7:run (default) @ ws-at --- > [INFO] Executing tasks > main: > [copy] Copying 12826 files to /home/hudson/workspace/narayana-performance/comparison/ws-at/target/server1 > [copy] Copied 4874 empty directories to 143 empty directories under /home/hudson/workspace/narayana-performance/comparison/ws-at/target/server1 > [copy] Copying 25652 files to /home/hudson/workspace/narayana-performance/comparison/ws-at/target/server2 > [copy] Copied 9748 empty directories to 286 empty directories under /home/hudson/workspace/narayana-performance/comparison/ws-at/target/server2 > [copy] Copying 51304 files to /home/hudson/workspace/narayana-performance/comparison/ws-at/target/server3 > [copy] Copied 19496 empty directories to 572 empty directories under /home/hudson/workspace/narayana-performance/comparison/ws-at/target/server3 > [INFO] ------------------------------------------------------------------------ > [INFO] Reactor Summary: > [INFO] > [INFO] comparison-parent .................................. SUCCESS [ 0.189 s] > [INFO] common ............................................. SUCCESS [ 1.305 s] > [INFO] ws-at .............................................. FAILURE [ 30.599 s] > [INFO] rest-at ............................................ SKIPPED > [INFO] jts ................................................ SKIPPED > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > [INFO] Total time: 32.244 s > [INFO] Finished at: 2018-03-25T00:07:53+00:00 > [INFO] Final Memory: 62M/680M > [INFO] ------------------------------------------------------------------------ > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.7:run (default) on project ws-at: An Ant BuildException has occured: Warning: Could not find file /home/hudson/workspace/narayana-performance/docs/examples/configs/standalone-xts.xml to copy. > [ERROR] around Ant part ...... @ 13:232 in /home/hudson/workspace/narayana-performance/comparison/ws-at/target/antrun/build-main.xml -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:17:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:17:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2996) Change the Narayana CI jobs to consider membership of PR author In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2996. ------------------------------- > Change the Narayana CI jobs to consider membership of PR author > --------------------------------------------------------------- > > Key: JBTM-2996 > URL: https://issues.jboss.org/browse/JBTM-2996 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Build System > Affects Versions: 5.7.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > It would be good to start using gihub webhooks instead of a poller jenkins cron job. > Configure the triggers in Jenkins and webhook on github and consider using the plugin > https://wiki.jenkins.io/display/JENKINS/GitHub+pull+request+builder+plugin -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:19:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:19:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2462) "Too many open files" failure in CI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2462. ------------------------------- > "Too many open files" failure in CI > ----------------------------------- > > Key: JBTM-2462 > URL: https://issues.jboss.org/browse/JBTM-2462 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Reporter: Gytis Trikleris > Assignee: Michael Musgrove > Priority: Critical > > Many CI builds fail to build WildFly because of too many open files. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:34:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:34: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 ] Tom Jenkinson closed JBTM-3038. ------------------------------- > 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: Task > Components: LRA > Affects Versions: 5.8.2.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.9.0.Final > > > 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 Thu Jul 5 05:34:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:34:01 -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: [ https://issues.jboss.org/browse/JBTM-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-3037. ------------------------------- > 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.9.0.Final > > > 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 Thu Jul 5 05:34:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:34:01 -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 ] Tom Jenkinson closed JBTM-3035. ------------------------------- > 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.9.0.Final > > > 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 Thu Jul 5 05:34:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:34:01 -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 ] Tom Jenkinson closed JBTM-3033. ------------------------------- > 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.9.0.Final > > > 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 Thu Jul 5 05:34:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:34: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:all-tabpanel ] Tom Jenkinson closed JBTM-3031. ------------------------------- > 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 > Fix For: 5.9.0.Final > > > 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 Thu Jul 5 05:34:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:34: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 ] Tom Jenkinson closed JBTM-3028. ------------------------------- > 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.9.0.Final > > > 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 Thu Jul 5 05:35:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3027) Failing LRA quickstarts as Narayana still reports dependency at lra annotations In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-3027. ------------------------------- > Failing LRA quickstarts as Narayana still reports dependency at lra annotations > ------------------------------------------------------------------------------- > > Key: JBTM-3027 > URL: https://issues.jboss.org/browse/JBTM-3027 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.8.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.9.0.Final > > > LRA quickstarts are failing ({{/home/ochaloup/Transactions/quickstart-jbosstm/rts/lra}}) because the fraction which is created from the {{lra-filters}} injects not only eclipse lra annotations but the narayana:lra-annotations dependency too. > There is fail on the injections with errors like > {code} > 2018-05-23 16:56:41,684 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-1) MSC000001: Failed to start service jboss.deployment.unit."lra-test.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."lra-test.war".WeldStartService: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type LRAClient with qualifiers @Default > at injection point [BackedAnnotatedField] @Inject private io.narayana.rts.lra.demo.flight.FlightService.lraClient > at io.narayana.rts.lra.demo.flight.FlightService.lraClient(FlightService.java:0) > at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:359) > at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:281) > at org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:134) > at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:155) > at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:518) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68) > at org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63) > at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:35:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3026) LRA tests cause issues when being built on machines/jdk preferring IPv6 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-3026. ------------------------------- > LRA tests cause issues when being built on machines/jdk preferring IPv6 > ----------------------------------------------------------------------- > > Key: JBTM-3026 > URL: https://issues.jboss.org/browse/JBTM-3026 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.8.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.9.0.Final > > > There is issue of running LRA tests which use {{org.honton.chas:process-exec-maven-plugin}} to start wildfly swarm container because Arquillian plugin is capable to start only one swarm container. That way the coordinator is started in {{pre-integration-test}} phase with that plugin. There is an issue when system prefers IPv6 then the port is not capable to be bound. > see {{rts/lra/lra-test/target//failsafe-reports/lra-coordinator-swarm-startup.log}} > {code} > [0m[0m2018-05-23 12:07:28,018 INFO??[org.xnio.nio] (MSC service thread 1-8) XNIO NIO Implementation Version 3.4.3.Final > [0m[0m2018-05-23 12:07:28,062 INFO??[org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0012: Started server default-server. > [0m[31m2018-05-23 12:07:28,099 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153) > ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > ??at java.lang.Thread.run(Thread.java:748) > Caused by: java.net.SocketException: Protocol family unavailable > ??at sun.nio.ch.Net.bind0(Native Method) > ??at sun.nio.ch.Net.bind(Net.java:433) > ??at sun.nio.ch.Net.bind(Net.java:425) > ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171) > ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245) > ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126) > ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142) > ??... 5 more > [0m[31m2018-05-23 12:07:28,126 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ????("subsystem" => "undertow"), > ????("server" => "default-server"), > ????("http-listener" => "default") > ]) - failure description: { > ????"WFLYCTL0080: Failed services" => {"jboss.undertow.listener.default" => "org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > ????Caused by: java.net.SocketException: Protocol family unavailable"}, > ????"WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.listener.default"], > ????"WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > [0m[0m2018-05-23 12:07:28,145 INFO??[org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0186:?? Services which failed to start:??????service jboss.undertow.listener.default: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > [0m[31m2018-05-23 12:07:28,180 ERROR [org.jboss.as] (Controller Boot Thread) WFLYSRV0026: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started (with errors) in 916ms - Started 85 of 96 services (1 services failed or missing dependencies, 18 services are lazy, passive or on-demand) > [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) java.lang.reflect.InvocationTargetException > [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at java.lang.reflect.Method.invoke(Method.java:498) > [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.MainInvoker.invoke(MainInvoker.java:39) > [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.run(Main.java:133) > [0m[31m2018-05-23 12:07:28,190 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.main(Main.java:86) > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) Caused by: java.lang.RuntimeException: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.spi.api.ClassLoading.withTCCL(ClassLoading.java:45) > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.container.runtime.ServerBootstrapImpl.bootstrap(ServerBootstrapImpl.java:114) > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.start(Swarm.java:372) > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.main(Swarm.java:628) > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??... 7 more > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) Caused by: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153) > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > [0m[31m2018-05-23 12:07:28,191 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at java.lang.Thread.run(Thread.java:748) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) Caused by: java.net.SocketException: Protocol family unavailable > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind0(Native Method) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:433) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:425) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245) > [0m[31m2018-05-23 12:07:28,192 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126) > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142) > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??... 5 more > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) Exception in thread "main" java.lang.reflect.InvocationTargetException > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at java.lang.reflect.Method.invoke(Method.java:498) > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.MainInvoker.invoke(MainInvoker.java:39) > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.run(Main.java:133) > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) ??at org.wildfly.swarm.bootstrap.Main.main(Main.java:86) > [0m[31m2018-05-23 12:07:28,193 ERROR [stderr] (main) Caused by: java.lang.RuntimeException: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.spi.api.ClassLoading.withTCCL(ClassLoading.java:45) > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.container.runtime.ServerBootstrapImpl.bootstrap(ServerBootstrapImpl.java:114) > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.start(Swarm.java:372) > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.swarm.Swarm.main(Swarm.java:628) > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??... 7 more > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) Caused by: org.jboss.msc.service.StartException in service jboss.undertow.listener.default: WFLYUT0082: Could not start 'default' listener. > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:153) > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) > [0m[31m2018-05-23 12:07:28,194 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at java.lang.Thread.run(Thread.java:748) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) Caused by: java.net.SocketException: Protocol family unavailable > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind0(Native Method) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:433) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.Net.bind(Net.java:425) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:171) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:245) > [0m[31m2018-05-23 12:07:28,195 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.HttpListenerService.startListening(HttpListenerService.java:126) > [0m[31m2018-05-23 12:07:28,196 ERROR [stderr] (main) ??at org.wildfly.extension.undertow.ListenerService.start(ListenerService.java:142) > [0m[31m2018-05-23 12:07:28,196 ERROR [stderr] (main) ??... 5 more > [0m[0m2018-05-23 12:07:55,607 INFO??[org.wildfly.swarm] (Thread-3) WFSWARM0027: Shutdown requested > [0m[0m2018-05-23 12:07:55,608 INFO??[org.jboss.as.server] (Thread-4) WFLYSRV0220: Server shutdown has been requested via an OS signal > [0m[0m2018-05-23 12:07:55,612 INFO??[org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0004: Undertow 1.4.11.Final stopping > [0m[0m2018-05-23 12:07:55,621 INFO??[org.jboss.as] (MSC service thread 1-7) WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 9ms > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:35:01 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3025) Xid created for JTS imported transaction set up wrong node name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-3025. ------------------------------- > Xid created for JTS imported transaction set up wrong node name > --------------------------------------------------------------- > > Key: JBTM-3025 > URL: https://issues.jboss.org/browse/JBTM-3025 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.8.2.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Critical > Fix For: 5.9.0.Final > > > For JTS being able to handle multiple inflow transactions there was made fix at https://issues.jboss.org/browse/JBTM-2893. Unfortunately the fix introduces issue where node name of the newly created Xid is incorrect. Even we have imported transaction which should be considered as subordinate we set up automatically node name equal to the current Narayana node. > I expect, the correct behavior should be to let the node name being the same as it was provided by import transaction call. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:35:02 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:02 -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 ] Tom Jenkinson closed JBTM-3017. ------------------------------- > 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.9.0.Final, 5.5.32.Final > > > 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 Jul 5 05:35:02 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:02 -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 ] Tom Jenkinson closed JBTM-2982. ------------------------------- > 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 > Fix For: 5.9.0.Final > > > 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 Thu Jul 5 05:35:02 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2979) Timeout leaves LRA active and able to complete In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2979. ------------------------------- > Timeout leaves LRA active and able to complete > ---------------------------------------------- > > Key: JBTM-2979 > URL: https://issues.jboss.org/browse/JBTM-2979 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Nicola Ferraro > Assignee: Michael Musgrove > Fix For: 5.9.0.Final > > > If a participant declares a timeout, the coordinator calls its "/compensate" endpoint when the timeout expires. But the LRA remains active and it may be possibly closed, leading to a second call to "/complete" on the participant, even if he has already compensated. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:35:02 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2978) Compensation should not be considered done in case of network error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2978. ------------------------------- > Compensation should not be considered done in case of network error > ------------------------------------------------------------------- > > Key: JBTM-2978 > URL: https://issues.jboss.org/browse/JBTM-2978 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Nicola Ferraro > Assignee: Michael Musgrove > Fix For: 5.9.0.Final > > > In case of network error on the call to "/compensate" made by the coordinator to the participant, the LRA is considered compensated, hence the compensate action is not retried again. This is not the expected behavior. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:35:02 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:02 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2977) Participants should not be told to compensate after completion In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2977. ------------------------------- > Participants should not be told to compensate after completion > -------------------------------------------------------------- > > Key: JBTM-2977 > URL: https://issues.jboss.org/browse/JBTM-2977 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Nicola Ferraro > Assignee: Michael Musgrove > Fix For: 5.9.0.Final > > > When a LRA is closed the coordinator behaves incorrectly if a participant is slow to respond. > While the call to "/complete" is still ongoing, the coordinator (recovery module) may issue a second call to "/compensate", making it impossible for the participant to determine when a LRA is really closed. > The LRA coordinator must choose a single outcome for the LRA and be consistent with that (retrying until all participants are in status complete/failedtocomplete in this case). > A second minor problem is that the call to "/close" is synchronous, and the caller is kept attached forever if the participant does not respond to "/complete". It would be better to establish a timeout and return a "Completing" status if not all participant are done in time. > I attach few simple steps to reproduce it with shell commands. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:35:02 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:02 -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 ] Tom Jenkinson closed JBTM-2966. ------------------------------- > 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.9.0.Final > > > 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 Thu Jul 5 05:35:02 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:02 -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 ] Tom Jenkinson closed JBTM-2965. ------------------------------- > 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.9.0.Final > > > 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 Thu Jul 5 05:35:03 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:03 -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 ] Tom Jenkinson updated JBTM-3029: -------------------------------- Fix Version/s: 5.next (was: 5.9.0.Final) > 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 Thu Jul 5 05:35:03 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:03 -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 ] Tom Jenkinson closed JBTM-2880. ------------------------------- > 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.9.0.Final > > > 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 Thu Jul 5 05:35:03 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:03 -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 ] Tom Jenkinson updated JBTM-3020: -------------------------------- Fix Version/s: 5.next (was: 5.9.0.Final) > 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 Thu Jul 5 05:35:03 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3019) Testsuite: Docker controller leaves stray volumes and fills up disk space unnecessairly over time In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3019: -------------------------------- Fix Version/s: 5.next (was: 5.9.0.Final) > Testsuite: Docker controller leaves stray volumes and fills up disk space unnecessairly over time > ------------------------------------------------------------------------------------------------- > > Key: JBTM-3019 > URL: https://issues.jboss.org/browse/JBTM-3019 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.8.1.Final > Environment: Docker enabled Jenkins slaves > Reporter: Michal Karm Babacek > Assignee: Michal Karm Babacek > Priority: Minor > Fix For: 5.next > > > h3. Problem > The Docker controller that allocates databases as Docker containers cleans up containers and does not leave unnecessary images: > {code} > [root at karm-centos7-x86-64 ~]# docker images > REPOSITORY TAG IMAGE ID CREATED SIZE > docker.io/postgres 9.4 26bd9b04b948 6 days ago 232 MB > docker.io/postgres 10 0965cdc98045 6 days ago 234 MB > docker.io/postgres ed5db6e669ff 7 weeks ago 263 MB > docker.io/postgres 30121e967865 7 weeks ago 289 MB > [root at karm-centos7-x86-64 ~]# docker ps -a > CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES > [root at karm-centos7-x86-64 ~]# > {code} > Although it leaves stray container volumes for some reason: > {code} > [root at karm-centos7-x86-64 ~]# du -hs /var/lib/docker-latest/volumes > 15G /var/lib/docker-latest/volumes > [root at karm-centos7-x86-64 ~]# docker volume ls -qf dangling=true | wc -l > 409 > {code} > It unnecessarily clogs the slaves' disk space. The 15G of garbage has been created over dozens and dozens of builds with at least two containers each, but it shouldn't be happening anyway. > h3. Call to action > Review whether [removeContainerCmd|https://github.com/jbosstm/narayana/blob/master/tools/src/main/java/io/narayana/db/PostgreContainerAllocator.java#L264] is supposed to be enough to not only remove the container but to also remove its volume. > h3. Workaround > {code} > docker volume prune > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:35:03 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3010) Move the tomcat-jta module out of the narayana repo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3010: -------------------------------- Fix Version/s: 5.next (was: 5.9.0.Final) > Move the tomcat-jta module out of the narayana repo > --------------------------------------------------- > > Key: JBTM-3010 > URL: https://issues.jboss.org/browse/JBTM-3010 > Project: JBoss Transaction Manager > Issue Type: Task > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > We tend to prefer the integration code for specific application servers be kept outside of the main Narayana transaction manager repository as it tends to iterate under different release cycle also. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:35:03 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:03 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3009) Add the Transactional datasource factory in the tomcat-jta In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3009: -------------------------------- Fix Version/s: 5.next (was: 5.9.0.Final) > Add the Transactional datasource factory in the tomcat-jta > ---------------------------------------------------------- > > Key: JBTM-3009 > URL: https://issues.jboss.org/browse/JBTM-3009 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > This factory is used to create the datasource with the common-dbcp2 and support XA and pooling, -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:35:04 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2968) Some JTS quickstarts run with JacORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2968: -------------------------------- Fix Version/s: 5.next (was: 5.9.0.Final) > Some JTS quickstarts run with JacORB > ------------------------------------ > > Key: JBTM-2968 > URL: https://issues.jboss.org/browse/JBTM-2968 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > Some of the JTS quickstarts are using JacORB. The narayana project has since changed the default ORB (OpenJDK ORB) so we should change the quickstarts to use the new default. The affected poms are: > ArjunaJTS/pom.xml > ArjunaJTS/standalone/pom.xml > ArjunaJTS/trailmap/pom.xml -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:35:04 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2967) Some quickstarts are not tested in CI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2967: -------------------------------- Fix Version/s: 5.next (was: 5.9.0.Final) > Some quickstarts are not tested in CI > ------------------------------------- > > Key: JBTM-2967 > URL: https://issues.jboss.org/browse/JBTM-2967 > 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 > > > Most quickstarts used to ship with a run.[sh|bat] script for running the quickstart and we used to test them in CI by executing the run script. At some point we changed the CI script (scripts/hudson/quickstart.sh) to just run the pom instead (./build.sh -B clean install). Since not all poms execute their run script we aren't getting full CI coverage. > This JIRA is to go through each quickstart and ensure the the pom does indeed exercise the quickstart. > The following poms do execute a run script > transactionaldriver-jpa-and-tomcat/pom.xml > rts/at/simple/pom.xml > rts/lra/lra-test/pom.xml > ArjunaJTS/interop/glassfish/pom.xml > transactionaldriver-and-tomcat/pom.xml > spring/camel-with-narayana-spring-boot/pom.xml > The following quickstarts contain run scripts: > transactionaldriver-jpa-and-tomcat/run.sh > ArjunaCore/txoj/run.sh > jboss-as/build/target/wildfly-9.0.0.CR1-SNAPSHOT/bin/run.sh > ArjunaJTA/object_store/run.sh > ArjunaJTA/maven/run.sh > ArjunaJTA/recovery/run.sh > ArjunaJTA/javax_transaction/run.sh > rts/at/undertow/run.sh > rts/at/recovery/recovery2/run.sh > rts/at/recovery/recovery1/run.sh > rts/at/simple/run.sh > rts/at/service/service2b/run.sh > rts/at/service/service2/run.sh > rts/at/service/service1b/run.sh > rts/at/service/service1/run.sh > rts/at/demo/run.sh > rts/lra/run.sh > ArjunaJTS/standalone/run.sh > ArjunaJTS/interop/glassfish/run.sh > ArjunaJTS/recovery/run.sh -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:35:04 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:04 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2913) Make the SPI a true dependency of standalone narayana-jta pom.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2913: -------------------------------- Fix Version/s: 5.next (was: 5.9.0.Final) > Make the SPI a true dependency of standalone narayana-jta pom.xml > ----------------------------------------------------------------- > > Key: JBTM-2913 > URL: https://issues.jboss.org/browse/JBTM-2913 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > This means that users can simply import the narayana-jta dependency rather than both it and the SPI. > It is useful when being consumed by jbpm for example. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:35:05 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2912) Upgrade JMS transactional driver to JMS 2.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2912: -------------------------------- Fix Version/s: 5.next (was: 5.9.0.Final) > Upgrade JMS transactional driver to JMS 2.0 > ------------------------------------------- > > Key: JBTM-2912 > URL: https://issues.jboss.org/browse/JBTM-2912 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JMS > Reporter: Tom Jenkinson > Fix For: 5.next > > > The transactional driver was implemented for JMS API 1.1. We should upgrade to 2.0. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:35:05 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2867) Investigate un-_workList protected access to _work object In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2867: -------------------------------- Fix Version/s: 5.next (was: 5.9.0.Final) > Investigate un-_workList protected access to _work object > --------------------------------------------------------- > > Key: JBTM-2867 > URL: https://issues.jboss.org/browse/JBTM-2867 > Project: JBoss Transaction Manager > Issue Type: Bug > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > During investigation of JBTM-2865 it was detected that the _work object can be accessed outside of the _workList synchronized block. Notably this seems to be a .remove() operation on it which can mutate the struct and may cause issues. > For example, this looks wrong: > https://github.com/tomjenkinson/narayana/blob/adda493b7bbd030eb405e3ef20978dc5d30ac5c2/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java#L703 > If > https://github.com/tomjenkinson/narayana/blob/adda493b7bbd030eb405e3ef20978dc5d30ac5c2/ArjunaCore/arjuna/classes/com/arjuna/ats/internal/arjuna/objectstore/CacheStore.java#L187 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:35:05 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2851) Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2851: -------------------------------- Fix Version/s: 5.next (was: 5.9.0.Final) > Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) > ------------------------------------------------------------------------------ > > Key: JBTM-2851 > URL: https://issues.jboss.org/browse/JBTM-2851 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > Fix For: 5.next > > > The blacktie-admin-service-ear is failed when deploying the ear to the wildfly running with the JDK9. It could be an issue [1] and should be fix in [2]. > So we have to build the openjdk-orb 8.0.8.Beta1-SNAPSHOT or wait it for the final release. > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-May/007698.html > [2] https://github.com/jboss/openjdk-orb/pull/4 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 5 05:35:05 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Thu, 5 Jul 2018 05:35:05 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2841) HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2841: -------------------------------- Fix Version/s: 5.next (was: 5.9.0.Final) > HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send() > ------------------------------------------------------------------------- > > Key: JBTM-2841 > URL: https://issues.jboss.org/browse/JBTM-2841 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.next > > > tpreturn() seems to non-block send without checking tranfer length. > It needs a wrapper of looping apr_socket_send() until all of the data write to the socket. > similar like [stomp_write_buffer|https://github.com/jbosstm/narayana/blob/c035f66960d189a5b96d1940c9d251a4e2d7b113/blacktie/hybrid/src/main/cpp/stomp.c] -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jul 10 04:41:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 10 Jul 2018 04:41:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3040) Include more logging in LRA state changes In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-3040: ----------------------------------- Summary: Include more logging in LRA state changes Key: JBTM-3040 URL: https://issues.jboss.org/browse/JBTM-3040 Project: JBoss Transaction Manager Issue Type: Task Components: LRA Reporter: Tom Jenkinson Assignee: Michael Musgrove We have a test that fails fairly regulary due to timeout: Tests run: 26, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 98.564 sec <<< FAILURE! - in io.narayana.lra.participant.SpecIT timeLimitRequiredLRA(io.narayana.lra.participant.SpecIT) Time elapsed: 0.868 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:608) Results : Failed tests: SpecIT.timeLimitRequiredLRA:608 timeLimitRequiredLRA: compensate should have been called expected:<1> but was:<0> -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jul 10 04:46:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 10 Jul 2018 04:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2998) Blacktie TestTPGetRply failed with unknown session In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2998: -------------------------------- Attachment: archive(1).zip archive.zip > Blacktie TestTPGetRply failed with unknown session > -------------------------------------------------- > > Key: JBTM-2998 > URL: https://issues.jboss.org/browse/JBTM-2998 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.later > > Attachments: archive(1).zip, archive.zip > > > {noformat} > 2018-01-09 02:24:48,064 [0x00001db8] DEBUG (AtmiBrokerClient :200 ) - get session: 3 > 2018-01-09 02:24:48,064 [0x00001db8] DEBUG (AtmiBrokerClient :209 ) - did not get session: 3 > 2018-01-09 02:24:48,064 [0x00001db8] TRACE (XATMIc :411 ) - _get_tperrno > 2018-01-09 02:24:48,064 [0x00001db8] TRACE (XATMIc :415 ) - found _get_tperrno2 > 2018-01-09 02:24:48,064 [0x00001db8] TRACE (XATMIc :418 ) - returning _get_tperrno2 > 2018-01-09 02:24:48,064 [0x00001db8] TRACE (XATMIc :924 ) - tpgetrply return: -1 tperrno: 2 > 2018-01-09 02:24:48,064 [0x00001db8] TRACE (XATMIc :411 ) - _get_tperrno > 2018-01-09 02:24:48,064 [0x00001db8] TRACE (XATMIc :415 ) - found _get_tperrno2 > 2018-01-09 02:24:48,064 [0x00001db8] TRACE (XATMIc :418 ) - returning _get_tperrno2 > 2018-01-09 02:24:48,064 [0x00001db8] DEBUG (AtmiBrokerLogc :72 ) - CHKCOND ASSERT FAILED C:\hudson\workspace\narayana-catelyn\blacktie\xatmi\src\test\cpp\TestTPGetRply.cxx:272 > {noformat} > It looks like that the sessionIds have the prev id in the other tests which has not been removed. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jul 13 06:57:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 13 Jul 2018 06:57:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3041) Include a test to run the microprofile-lra TCK In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-3041: -------------------------------------- Summary: Include a test to run the microprofile-lra TCK Key: JBTM-3041 URL: https://issues.jboss.org/browse/JBTM-3041 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA, Testing Affects Versions: 5.9.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The narayana implementation of the LRA spec should include a test to validate that it conforms to the TCK at https://github.com/eclipse/microprofile-lra/tree/master/tck -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jul 13 11:27:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 13 Jul 2018 11:27:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3040) Include more logging in LRA state changes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1345 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Include more logging in LRA state changes > ----------------------------------------- > > Key: JBTM-3040 > URL: https://issues.jboss.org/browse/JBTM-3040 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > > We have a test that fails fairly regulary due to timeout: > Tests run: 26, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 98.564 sec <<< FAILURE! - in io.narayana.lra.participant.SpecIT > timeLimitRequiredLRA(io.narayana.lra.participant.SpecIT) Time elapsed: 0.868 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:608) > Results : > Failed tests: > SpecIT.timeLimitRequiredLRA:608 timeLimitRequiredLRA: compensate should have been called expected:<1> but was:<0> -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sat Jul 14 14:14:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Sat, 14 Jul 2018 14:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3041) Include a test to run the microprofile-lra TCK In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3041: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1345 > Include a test to run the microprofile-lra TCK > ---------------------------------------------- > > Key: JBTM-3041 > URL: https://issues.jboss.org/browse/JBTM-3041 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA, Testing > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The narayana implementation of the LRA spec should include a test to validate that it conforms to the TCK at https://github.com/eclipse/microprofile-lra/tree/master/tck -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 11:08:05 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 16 Jul 2018 11:08:05 -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: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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 > Attachments: JBTM-3034-xarm-to-query-cmrrm.diff > > > 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 Jul 16 11:55:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 16 Jul 2018 11:55: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 ] Ondra Chaloupka reopened JBTM-2880: ----------------------------------- I'm reopening the issue as it was not fixed altogether. There are still plenty of spaces in the code which use the {{e.printStackTrace()}} call. See {code} git clone https://github.com/jbosstm/narayana find -L narayana -type f -iname *java -print0 | xargs -0 grep -i -B 0 -A 0 -- e.printStackTrace {code} > 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.9.0.Final > > > 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 Jul 16 11:59:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 11:59: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 ] Tom Jenkinson updated JBTM-3034: -------------------------------- Fix Version/s: 5.9.0.Final > 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 > Fix For: 5.9.0.Final > > Attachments: JBTM-3034-xarm-to-query-cmrrm.diff > > > 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 Jul 16 11:59:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 11:59: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 ] Tom Jenkinson closed JBTM-3034. ------------------------------- > 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 > Fix For: 5.9.0.Final > > Attachments: JBTM-3034-xarm-to-query-cmrrm.diff > > > 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 Jul 16 12:01:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 12:01:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2500) Update version of jboss-logging to 3.1.4.GA In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2500. ------------------------------- > Update version of jboss-logging to 3.1.4.GA > ------------------------------------------- > > Key: JBTM-2500 > URL: https://issues.jboss.org/browse/JBTM-2500 > Project: JBoss Transaction Manager > Issue Type: Component Upgrade > Components: SPI > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > > Upgrade the version of jboss-logging to latest version. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:02:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 12:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2686) Introduce a Heuristic example in the karaf osgi-jta quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2686: -------------------------------- Fix Version/s: 5.3.4.Final > Introduce a Heuristic example in the karaf osgi-jta quickstart > -------------------------------------------------------------- > > Key: JBTM-2686 > URL: https://issues.jboss.org/browse/JBTM-2686 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.3.4.Final > > > This example could be used to show how to mange the transaction object stores with the karaf cli commands. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:02:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 12:02:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2686) Introduce a Heuristic example in the karaf osgi-jta quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2686. ------------------------------- > Introduce a Heuristic example in the karaf osgi-jta quickstart > -------------------------------------------------------------- > > Key: JBTM-2686 > URL: https://issues.jboss.org/browse/JBTM-2686 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Demonstrator > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.3.4.Final > > > This example could be used to show how to mange the transaction object stores with the karaf cli commands. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:03:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 12:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2457) Upgrade the wildfly to 10.0.0.Alpha6-SNAPSHOT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2457: -------------------------------- Fix Version/s: 5.2.1 > Upgrade the wildfly to 10.0.0.Alpha6-SNAPSHOT > --------------------------------------------- > > Key: JBTM-2457 > URL: https://issues.jboss.org/browse/JBTM-2457 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.2.1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:03:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 12:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2457) Upgrade the wildfly to 10.0.0.Alpha6-SNAPSHOT In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2457. ------------------------------- > Upgrade the wildfly to 10.0.0.Alpha6-SNAPSHOT > --------------------------------------------- > > Key: JBTM-2457 > URL: https://issues.jboss.org/browse/JBTM-2457 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Application Server Integration > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.2.1 > > -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:03:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 12:03:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2776) Investigate the arquillian tests failure with the JDK 9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2776. ------------------------------- > Investigate the arquillian tests failure with the JDK 9 > ------------------------------------------------------- > > Key: JBTM-2776 > URL: https://issues.jboss.org/browse/JBTM-2776 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Build System > Reporter: Amos Feng > Assignee: Amos Feng > Labels: jdk9 > > the arquillian can not create the container -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:04:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 12:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2687) There are typos in DisabledContextPropagationTests and EnabledContextPropagationTests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2687: -------------------------------- Fix Version/s: 5.3.4.Final > There are typos in DisabledContextPropagationTests and EnabledContextPropagationTests > ------------------------------------------------------------------------------------- > > Key: JBTM-2687 > URL: https://issues.jboss.org/browse/JBTM-2687 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing, TxBridge > Affects Versions: 5.3.3.Final > Reporter: Daniel Simko > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.3.4.Final > > > There are three times: > {code}parameters.add(new BasicNameValuePair("isTransaction", "ture"));{code} > instead of > {code}parameters.add(new BasicNameValuePair("isTransaction", "true"));{code} > which affect test behavior. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:04:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 12:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2687) There are typos in DisabledContextPropagationTests and EnabledContextPropagationTests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2687. ------------------------------- > There are typos in DisabledContextPropagationTests and EnabledContextPropagationTests > ------------------------------------------------------------------------------------- > > Key: JBTM-2687 > URL: https://issues.jboss.org/browse/JBTM-2687 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing, TxBridge > Affects Versions: 5.3.3.Final > Reporter: Daniel Simko > Assignee: Gytis Trikleris > Priority: Minor > Fix For: 5.3.4.Final > > > There are three times: > {code}parameters.add(new BasicNameValuePair("isTransaction", "ture"));{code} > instead of > {code}parameters.add(new BasicNameValuePair("isTransaction", "true"));{code} > which affect test behavior. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:04:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 12:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2631) UidTest qa test suite (with the journal store) failures In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2631: -------------------------------- Fix Version/s: 5.3.0.Final > UidTest qa test suite (with the journal store) failures > ------------------------------------------------------- > > Key: JBTM-2631 > URL: https://issues.jboss.org/browse/JBTM-2631 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.2.14.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.3.0.Final > > Attachments: testoutput.jacorb.hqstore.tar > > > CI job http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-hqstore/151/PROFILE=QA_JTA,jdk=jdk8.latest,label=linux/ failed with various uid test failures: > {quote} > txcore Uid_Test011 Fail (0m18.180s) > txcore Uid_Test011 Fail (0m19.431s) > txcore Uid_Test012 Fail (0m20.850s) > txcore Uid_Test004 Fail (0m11.566s) > txcore Uid_Test005 Fail (0m12.343s) > txcore Uid_Test006 Fail (0m12.062s) > txcore Uid_Test007 Fail (0m15.742s) > txcore Uid_Test008 Fail (0m16.908s) > txcore Uid_Test009 Fail (0m17.282s) > txcore_lockrecord LockRecord_Thread_Test036a Fail (8m12.773s) > txcore_lockrecord LockRecord_Thread_Test036b Fail (8m10.265s) > txcore_lockrecord LockRecord_Thread_Test048a Fail (8m11.115s) > txcore_lockrecord LockRecord_Thread_Test048b Fail (8m7.376s) > {quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:04:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 12:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2631) UidTest qa test suite (with the journal store) failures In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2631. ------------------------------- > UidTest qa test suite (with the journal store) failures > ------------------------------------------------------- > > Key: JBTM-2631 > URL: https://issues.jboss.org/browse/JBTM-2631 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Testing > Affects Versions: 5.2.14.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.3.0.Final > > Attachments: testoutput.jacorb.hqstore.tar > > > CI job http://albany.eng.hst.ams2.redhat.com/view/Narayana/job/narayana-hqstore/151/PROFILE=QA_JTA,jdk=jdk8.latest,label=linux/ failed with various uid test failures: > {quote} > txcore Uid_Test011 Fail (0m18.180s) > txcore Uid_Test011 Fail (0m19.431s) > txcore Uid_Test012 Fail (0m20.850s) > txcore Uid_Test004 Fail (0m11.566s) > txcore Uid_Test005 Fail (0m12.343s) > txcore Uid_Test006 Fail (0m12.062s) > txcore Uid_Test007 Fail (0m15.742s) > txcore Uid_Test008 Fail (0m16.908s) > txcore Uid_Test009 Fail (0m17.282s) > txcore_lockrecord LockRecord_Thread_Test036a Fail (8m12.773s) > txcore_lockrecord LockRecord_Thread_Test036b Fail (8m10.265s) > txcore_lockrecord LockRecord_Thread_Test048a Fail (8m11.115s) > txcore_lockrecord LockRecord_Thread_Test048b Fail (8m7.376s) > {quote} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:04:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 12:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2430) Update openjdk-orb library to 8.0.4.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2430: -------------------------------- Fix Version/s: 5.2.0 > Update openjdk-orb library to 8.0.4.Final > ----------------------------------------- > > Key: JBTM-2430 > URL: https://issues.jboss.org/browse/JBTM-2430 > Project: JBoss Transaction Manager > Issue Type: Component Upgrade > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.2.0 > > > openjdk-orb library needs updating to 8.0.4.Final which reverts a change made in 8.0.2.Final that allowed runner threads to finish before shutdown. > Tomek I cannot find any reference to why you reverted the change - do you have one? -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:04:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 12:04:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2430) Update openjdk-orb library to 8.0.4.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2430. ------------------------------- > Update openjdk-orb library to 8.0.4.Final > ----------------------------------------- > > Key: JBTM-2430 > URL: https://issues.jboss.org/browse/JBTM-2430 > Project: JBoss Transaction Manager > Issue Type: Component Upgrade > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.2.0 > > > openjdk-orb library needs updating to 8.0.4.Final which reverts a change made in 8.0.2.Final that allowed runner threads to finish before shutdown. > Tomek I cannot find any reference to why you reverted the change - do you have one? -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:05:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 12:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2930) Recovery is not supported by the LRA implementation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2930: -------------------------------- Fix Version/s: 5.7.0.Final > Recovery is not supported by the LRA implementation > --------------------------------------------------- > > Key: JBTM-2930 > URL: https://issues.jboss.org/browse/JBTM-2930 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.0.Final > > > The LRA implementation is missing recovery support. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:05:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 16 Jul 2018 12:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3040) Include more logging in LRA state changes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3040: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Include more logging in LRA state changes > ----------------------------------------- > > Key: JBTM-3040 > URL: https://issues.jboss.org/browse/JBTM-3040 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > > We have a test that fails fairly regulary due to timeout: > Tests run: 26, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 98.564 sec <<< FAILURE! - in io.narayana.lra.participant.SpecIT > timeLimitRequiredLRA(io.narayana.lra.participant.SpecIT) Time elapsed: 0.868 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:608) > Results : > Failed tests: > SpecIT.timeLimitRequiredLRA:608 timeLimitRequiredLRA: compensate should have been called expected:<1> but was:<0> -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:05:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 12:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2930) Recovery is not supported by the LRA implementation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2930. ------------------------------- > Recovery is not supported by the LRA implementation > --------------------------------------------------- > > Key: JBTM-2930 > URL: https://issues.jboss.org/browse/JBTM-2930 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.7.0.Final > > > The LRA implementation is missing recovery support. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:06:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 16 Jul 2018 12:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3041) Include a test to run the microprofile-lra TCK In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3041: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Include a test to run the microprofile-lra TCK > ---------------------------------------------- > > Key: JBTM-3041 > URL: https://issues.jboss.org/browse/JBTM-3041 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA, Testing > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The narayana implementation of the LRA spec should include a test to validate that it conforms to the TCK at https://github.com/eclipse/microprofile-lra/tree/master/tck -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:06:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 12:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2882) Automatize XTS ssl quickstart to be tested in CI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2882: -------------------------------- Fix Version/s: 5.6.0.Final > Automatize XTS ssl quickstart to be tested in CI > ------------------------------------------------ > > Key: JBTM-2882 > URL: https://issues.jboss.org/browse/JBTM-2882 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: XTS > Affects Versions: 5.5.6.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.6.0.Final > > > The ssl XTS quickstart is not automatize to be run in CI testing. Paul created nice document with steps > https://github.com/jbosstm/quickstart/tree/master/XTS/ssl > but it can't be used in CI. > The goal of this enhancement is automatize steps described in the quickstart (plus adjust quickstart REAME.md if not appropriate) and get the quickstart being run in CI. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:06:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 12:06:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2882) Automatize XTS ssl quickstart to be tested in CI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2882. ------------------------------- > Automatize XTS ssl quickstart to be tested in CI > ------------------------------------------------ > > Key: JBTM-2882 > URL: https://issues.jboss.org/browse/JBTM-2882 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: XTS > Affects Versions: 5.5.6.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.6.0.Final > > > The ssl XTS quickstart is not automatize to be run in CI testing. Paul created nice document with steps > https://github.com/jbosstm/quickstart/tree/master/XTS/ssl > but it can't be used in CI. > The goal of this enhancement is automatize steps described in the quickstart (plus adjust quickstart REAME.md if not appropriate) and get the quickstart being run in CI. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:07:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 12:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2921) RTS-AT: in case of one phase commit processing 'commit' link is invoked instead of 'commit-one-phase' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2921: -------------------------------- Fix Version/s: 5.7.0.Final > RTS-AT: in case of one phase commit processing 'commit' link is invoked instead of 'commit-one-phase' > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2921 > URL: https://issues.jboss.org/browse/JBTM-2921 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.6.3.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.7.0.Final > > > For REST-AT transactions is defined that for two phase unaware participant when link 'commit-one-phase' is introduced then it is expected that in the case of processing one phase commit this link will be invoked on the participant (see https://github.com/jbosstm/documentation/blob/master/rts/docs/RESTAT-v2-latest.pdf) > The current implementation does not consider the existence of this proposed link handler and calls always 'commit'. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:07:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 12:07:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2921) RTS-AT: in case of one phase commit processing 'commit' link is invoked instead of 'commit-one-phase' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2921. ------------------------------- > RTS-AT: in case of one phase commit processing 'commit' link is invoked instead of 'commit-one-phase' > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2921 > URL: https://issues.jboss.org/browse/JBTM-2921 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.6.3.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.7.0.Final > > > For REST-AT transactions is defined that for two phase unaware participant when link 'commit-one-phase' is introduced then it is expected that in the case of processing one phase commit this link will be invoked on the participant (see https://github.com/jbosstm/documentation/blob/master/rts/docs/RESTAT-v2-latest.pdf) > The current implementation does not consider the existence of this proposed link handler and calls always 'commit'. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 12:13:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 16 Jul 2018 12:13:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3042) API to get detailed LRA information should not include stats type data In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-3042: -------------------------------------- Summary: API to get detailed LRA information should not include stats type data Key: JBTM-3042 URL: https://issues.jboss.org/browse/JBTM-3042 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.9.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The interface to obtain information about an LRA [1] includes data such as when the LRA was started and ended. This type of information is more appropriate to monitoring and statistics gathering rather than core LRA info. Not all implementations may want to / be able to report these accurately so perhaps move them to an extended optional interface [1] https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-client/src/main/java/io/narayana/lra/client/LRAInfoImpl.java#L90 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 17:12:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 17:12:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2790) Blacktie btadmin ResumeDomainTest failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2790: -------------------------------- Fix Version/s: 5.5.0.Final > Blacktie btadmin ResumeDomainTest failure > ----------------------------------------- > > Key: JBTM-2790 > URL: https://issues.jboss.org/browse/JBTM-2790 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Testing > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.5.0.Final > > > It looks like the ResumeDomainTest.setUp() sends the "pauseDomain' command but can not receive the response from the jboss-as server. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 17:13:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 17:13:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2790) Blacktie btadmin ResumeDomainTest failure In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2790. ------------------------------- Resolution: Done > Blacktie btadmin ResumeDomainTest failure > ----------------------------------------- > > Key: JBTM-2790 > URL: https://issues.jboss.org/browse/JBTM-2790 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie, Testing > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.5.0.Final > > > It looks like the ResumeDomainTest.setUp() sends the "pauseDomain' command but can not receive the response from the jboss-as server. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 17:14:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 17:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3009) Add the Transactional datasource factory in the tomcat-jta In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-3009: -------------------------------- Fix Version/s: 5.8.2.Final (was: 5.next) > Add the Transactional datasource factory in the tomcat-jta > ---------------------------------------------------------- > > Key: JBTM-3009 > URL: https://issues.jboss.org/browse/JBTM-3009 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.8.2.Final > > > This factory is used to create the datasource with the common-dbcp2 and support XA and pooling, -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 17:14:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 17:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3009) Add the Transactional datasource factory in the tomcat-jta In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-3009. ------------------------------- Resolution: Done > Add the Transactional datasource factory in the tomcat-jta > ---------------------------------------------------------- > > Key: JBTM-3009 > URL: https://issues.jboss.org/browse/JBTM-3009 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Amos Feng > Assignee: Amos Feng > Fix For: 5.8.2.Final > > > This factory is used to create the datasource with the common-dbcp2 and support XA and pooling, -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 17:14:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 17:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2913) Make the SPI a true dependency of standalone narayana-jta pom.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2913: -------------------------------- Fix Version/s: 5.6.2.Final (was: 5.next) > Make the SPI a true dependency of standalone narayana-jta pom.xml > ----------------------------------------------------------------- > > Key: JBTM-2913 > URL: https://issues.jboss.org/browse/JBTM-2913 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.6.2.Final > > > This means that users can simply import the narayana-jta dependency rather than both it and the SPI. > It is useful when being consumed by jbpm for example. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 17:15:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 17:15:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2913) Make the SPI a true dependency of standalone narayana-jta pom.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson closed JBTM-2913. ------------------------------- Resolution: Done > Make the SPI a true dependency of standalone narayana-jta pom.xml > ----------------------------------------------------------------- > > Key: JBTM-2913 > URL: https://issues.jboss.org/browse/JBTM-2913 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.6.2.Final > > > This means that users can simply import the narayana-jta dependency rather than both it and the SPI. > It is useful when being consumed by jbpm for example. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 17:15:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 17:15:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2110) Investigate support for IBM ORB In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2110: -------------------------------- Status: Open (was: Pull Request Sent) > Investigate support for IBM ORB > ------------------------------- > > Key: JBTM-2110 > URL: https://issues.jboss.org/browse/JBTM-2110 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: JTS > Reporter: Tom Jenkinson > Assignee: Michael Musgrove > Fix For: 5.later > > -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 17:15:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 17:15:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1107) Recovery Support in Compensation API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-1107: -------------------------------- Status: Open (was: Pull Request Sent) > Recovery Support in Compensation API > ------------------------------------ > > Key: JBTM-1107 > URL: https://issues.jboss.org/browse/JBTM-1107 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Compensations > Reporter: Tom Jenkinson > Assignee: Ondra Chaloupka > Fix For: 5.later > > > *Background* > Currently Compensations API cannot handle system failures. Transaction state is not persisted in any stage. Thus no handlers will be invoked in case of the system crash. > *Requirements* > # Make handlers persistable (CompensationHandler, ConfirmationHandler, TransactionLoggedHandler). > ## Require Serializable interface. > ## Create PersistableHandler interface (similar to PersistableParticipant in RTS integration). > # Make participant persistable (ParticipantImpl, LocalParticipant, RemoteParticipant). > ## Make transaction identifier persistable (converting it to String should work). > ## Implement PersistableParticipant in ParticipantImpl. > ## Investigate if PARTICIPANT_COUNTERS in ParticipatnImpl have to be updated. > # Make compensation scoped beans persistable. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 17:15:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 17:15: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 ] Tom Jenkinson updated JBTM-3020: -------------------------------- Status: Open (was: Pull Request Sent) > 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 Mon Jul 16 17:23:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 17:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2851) Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2851: -------------------------------- Fix Version/s: (was: 5.next) > Upgrade BlackTie to a version of WildFly that works with JDK9 (when available) > ------------------------------------------------------------------------------ > > Key: JBTM-2851 > URL: https://issues.jboss.org/browse/JBTM-2851 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: BlackTie > Reporter: Tom Jenkinson > Assignee: Amos Feng > > The blacktie-admin-service-ear is failed when deploying the ear to the wildfly running with the JDK9. It could be an issue [1] and should be fix in [2]. > So we have to build the openjdk-orb 8.0.8.Beta1-SNAPSHOT or wait it for the final release. > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-May/007698.html > [2] https://github.com/jboss/openjdk-orb/pull/4 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Jul 16 17:23:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 16 Jul 2018 17:23:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2841) HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send() In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2841: -------------------------------- Fix Version/s: (was: 5.next) > HybridSocketEndpointQueue::_send() needs wrapper around apr_socket_send() > ------------------------------------------------------------------------- > > Key: JBTM-2841 > URL: https://issues.jboss.org/browse/JBTM-2841 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > > tpreturn() seems to non-block send without checking tranfer length. > It needs a wrapper of looping apr_socket_send() until all of the data write to the socket. > similar like [stomp_write_buffer|https://github.com/jbosstm/narayana/blob/c035f66960d189a5b96d1940c9d251a4e2d7b113/blacktie/hybrid/src/main/cpp/stomp.c] -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jul 17 04:34:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 17 Jul 2018 04:34: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 resolved JBTM-3029. ------------------------------------ Resolution: Duplicate Resolved as a side effect of fixing JBTM-3041 > 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 Tue Jul 17 05:05:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 17 Jul 2018 05:05:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3043) REST-AT to JTA Bridge Quickstart failing In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-3043: -------------------------------------- Summary: REST-AT to JTA Bridge Quickstart failing Key: JBTM-3043 URL: https://issues.jboss.org/browse/JBTM-3043 Project: JBoss Transaction Manager Issue Type: Bug Components: REST Affects Versions: 5.9.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Priority: Critical Fix For: 5.next ------------------------------------------------------- Running org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest Tests run: 4, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 6.973 sec <<< FAILURE! - in org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest testCommitWithTwoTasks(org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest) Time elapsed: 0.8 sec <<< FAILURE! java.lang.AssertionError: expected:<201> but was:<500> at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.createTask(TaskResourceTest.java:190) at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.testCommitWithTwoTasks(TaskResourceTest.java:147) testRollback(org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest) Time elapsed: 0.094 sec <<< FAILURE! java.lang.AssertionError: expected:<201> but was:<500> at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.createTask(TaskResourceTest.java:190) at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.testRollback(TaskResourceTest.java:130) testCommit(org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest) Time elapsed: 0.066 sec <<< FAILURE! java.lang.AssertionError: expected:<201> but was:<500> at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.createTask(TaskResourceTest.java:190) at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.testCommit(TaskResourceTest.java:111) testRollbackWithTwoTasks(org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest) Time elapsed: 0.063 sec <<< FAILURE! java.lang.AssertionError: expected:<201> but was:<500> at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.createTask(TaskResourceTest.java:190) at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.testRollbackWithTwoTasks(TaskResourceTest.java:169) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jul 17 06:26:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 17 Jul 2018 06:26:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3043) REST-AT to JTA Bridge Quickstart failing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13606088#comment-13606088 ] Michael Musgrove commented on JBTM-3043: ---------------------------------------- The issue is that hibernate have removed support for legacy style queries {quote} QueryException: Legacy-style query parameters (`?`) are no longer supported {quote} The fix is to replace them all with JPA style queries. > REST-AT to JTA Bridge Quickstart failing > ---------------------------------------- > > Key: JBTM-3043 > URL: https://issues.jboss.org/browse/JBTM-3043 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > ------------------------------------------------------- > Running org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest > Tests run: 4, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 6.973 sec <<< FAILURE! - in org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest > testCommitWithTwoTasks(org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest) Time elapsed: 0.8 sec <<< FAILURE! > java.lang.AssertionError: expected:<201> but was:<500> > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.createTask(TaskResourceTest.java:190) > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.testCommitWithTwoTasks(TaskResourceTest.java:147) > testRollback(org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest) Time elapsed: 0.094 sec <<< FAILURE! > java.lang.AssertionError: expected:<201> but was:<500> > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.createTask(TaskResourceTest.java:190) > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.testRollback(TaskResourceTest.java:130) > testCommit(org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest) Time elapsed: 0.066 sec <<< FAILURE! > java.lang.AssertionError: expected:<201> but was:<500> > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.createTask(TaskResourceTest.java:190) > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.testCommit(TaskResourceTest.java:111) > testRollbackWithTwoTasks(org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest) Time elapsed: 0.063 sec <<< FAILURE! > java.lang.AssertionError: expected:<201> but was:<500> > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.createTask(TaskResourceTest.java:190) > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.testRollbackWithTwoTasks(TaskResourceTest.java:169) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jul 18 17:12:00 2018 From: issues at jboss.org (Laird Nelson (JIRA)) Date: Wed, 18 Jul 2018 17:12:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3044) Decouple TransactionContext from JNDI In-Reply-To: References: Message-ID: Laird Nelson created JBTM-3044: ---------------------------------- Summary: Decouple TransactionContext from JNDI Key: JBTM-3044 URL: https://issues.jboss.org/browse/JBTM-3044 Project: JBoss Transaction Manager Issue Type: Enhancement Components: JTA Affects Versions: 5.9.0.Final Reporter: Laird Nelson I've submitted a [pull request|https://github.com/jbosstm/narayana/pull/1346] that makes the CDI pieces of the Narayana project play more nicely with dependency injection in general. There has been a [lengthy discussion|https://developer.jboss.org/thread/278367] of the issues. [~tomjenkinson] indicated I should file an issue here to track it, so here it is. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jul 20 04:42:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 20 Jul 2018 04:42:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3044) Decouple TransactionContext from JNDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson reassigned JBTM-3044: ----------------------------------- Assignee: Laird Nelson > Decouple TransactionContext from JNDI > ------------------------------------- > > Key: JBTM-3044 > URL: https://issues.jboss.org/browse/JBTM-3044 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Affects Versions: 5.9.0.Final > Reporter: Laird Nelson > Assignee: Laird Nelson > > I've submitted a [pull request|https://github.com/jbosstm/narayana/pull/1346] that makes the CDI pieces of the Narayana project play more nicely with dependency injection in general. > There has been a [lengthy discussion|https://developer.jboss.org/thread/278367] of the issues. > [~tomjenkinson] indicated I should file an issue here to track it, so here it is. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Jul 20 04:43:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 20 Jul 2018 04:43:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3044) Decouple TransactionContext from JNDI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-3044. --------------------------------- Fix Version/s: 5.next Resolution: Done > Decouple TransactionContext from JNDI > ------------------------------------- > > Key: JBTM-3044 > URL: https://issues.jboss.org/browse/JBTM-3044 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Affects Versions: 5.9.0.Final > Reporter: Laird Nelson > Assignee: Laird Nelson > Fix For: 5.next > > > I've submitted a [pull request|https://github.com/jbosstm/narayana/pull/1346] that makes the CDI pieces of the Narayana project play more nicely with dependency injection in general. > There has been a [lengthy discussion|https://developer.jboss.org/thread/278367] of the issues. > [~tomjenkinson] indicated I should file an issue here to track it, so here it is. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jul 24 06:18:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 24 Jul 2018 06:18:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3043) REST-AT to JTA Bridge Quickstart failing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #231 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > REST-AT to JTA Bridge Quickstart failing > ---------------------------------------- > > Key: JBTM-3043 > URL: https://issues.jboss.org/browse/JBTM-3043 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > ------------------------------------------------------- > Running org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest > Tests run: 4, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 6.973 sec <<< FAILURE! - in org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest > testCommitWithTwoTasks(org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest) Time elapsed: 0.8 sec <<< FAILURE! > java.lang.AssertionError: expected:<201> but was:<500> > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.createTask(TaskResourceTest.java:190) > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.testCommitWithTwoTasks(TaskResourceTest.java:147) > testRollback(org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest) Time elapsed: 0.094 sec <<< FAILURE! > java.lang.AssertionError: expected:<201> but was:<500> > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.createTask(TaskResourceTest.java:190) > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.testRollback(TaskResourceTest.java:130) > testCommit(org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest) Time elapsed: 0.066 sec <<< FAILURE! > java.lang.AssertionError: expected:<201> but was:<500> > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.createTask(TaskResourceTest.java:190) > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.testCommit(TaskResourceTest.java:111) > testRollbackWithTwoTasks(org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest) Time elapsed: 0.063 sec <<< FAILURE! > java.lang.AssertionError: expected:<201> but was:<500> > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.createTask(TaskResourceTest.java:190) > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.testRollbackWithTwoTasks(TaskResourceTest.java:169) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jul 24 06:44:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 24 Jul 2018 06:44:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3045) Standalone JTA 1.2 Quickstart failure In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-3045: -------------------------------------- Summary: Standalone JTA 1.2 Quickstart failure Key: JBTM-3045 URL: https://issues.jboss.org/browse/JBTM-3045 Project: JBoss Transaction Manager Issue Type: Bug Components: Demonstrator Affects Versions: 5.9.0.Final Reporter: Michael Musgrove Fix For: 5.next The recent changes to our JTA CDI support (https://issues.jboss.org/browse/JBTM-3044) have either caused a regression or the Standalone JTA 1.2 Quickstart needs updating. The failure is: {quote} testMandatoryTransactionWithExistingTransaction(org.jboss.narayana.quickstarts.jta.TestCase) Time elapsed: 0.536 sec <<< ERROR! javax.enterprise.inject.CreationException: Not a compound name: TransactionManager {quote} See for example CI run http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-quickstarts/159/console -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jul 24 06:45:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 24 Jul 2018 06:45:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3045) JTA CDI regression (or Standalone JTA 1.2 Quickstart failure) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3045: ----------------------------------- Summary: JTA CDI regression (or Standalone JTA 1.2 Quickstart failure) (was: Standalone JTA 1.2 Quickstart failure) > JTA CDI regression (or Standalone JTA 1.2 Quickstart failure) > ------------------------------------------------------------- > > Key: JBTM-3045 > URL: https://issues.jboss.org/browse/JBTM-3045 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Fix For: 5.next > > > The recent changes to our JTA CDI support (https://issues.jboss.org/browse/JBTM-3044) have either caused a regression or the Standalone JTA 1.2 Quickstart needs updating. The failure is: > {quote} > testMandatoryTransactionWithExistingTransaction(org.jboss.narayana.quickstarts.jta.TestCase) Time elapsed: 0.536 sec <<< ERROR! > javax.enterprise.inject.CreationException: Not a compound name: TransactionManager > {quote} > See for example CI run http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-quickstarts/159/console -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jul 24 06:46:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 24 Jul 2018 06:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3045) JTA CDI regression (or Standalone JTA 1.2 Quickstart failure) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3045: ----------------------------------- Description: The recent changes to our JTA CDI support (https://issues.jboss.org/browse/JBTM-3044) have either caused a regression or the Standalone JTA 1.2 Quickstart needs updating. The failure is: {quote} testMandatoryTransactionWithExistingTransaction(org.jboss.narayana.quickstarts.jta.TestCase) Time elapsed: 0.536 sec <<< ERROR! javax.enterprise.inject.CreationException: Not a compound name: TransactionManager {quote} See for example CI run http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-quickstarts/159/console If the issue does turn out to be a regression then the priority needs to be marked as Critical. was: The recent changes to our JTA CDI support (https://issues.jboss.org/browse/JBTM-3044) have either caused a regression or the Standalone JTA 1.2 Quickstart needs updating. The failure is: {quote} testMandatoryTransactionWithExistingTransaction(org.jboss.narayana.quickstarts.jta.TestCase) Time elapsed: 0.536 sec <<< ERROR! javax.enterprise.inject.CreationException: Not a compound name: TransactionManager {quote} See for example CI run http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-quickstarts/159/console > JTA CDI regression (or Standalone JTA 1.2 Quickstart failure) > ------------------------------------------------------------- > > Key: JBTM-3045 > URL: https://issues.jboss.org/browse/JBTM-3045 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Fix For: 5.next > > > The recent changes to our JTA CDI support (https://issues.jboss.org/browse/JBTM-3044) have either caused a regression or the Standalone JTA 1.2 Quickstart needs updating. The failure is: > {quote} > testMandatoryTransactionWithExistingTransaction(org.jboss.narayana.quickstarts.jta.TestCase) Time elapsed: 0.536 sec <<< ERROR! > javax.enterprise.inject.CreationException: Not a compound name: TransactionManager > {quote} > See for example CI run http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-quickstarts/159/console > If the issue does turn out to be a regression then the priority needs to be marked as Critical. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jul 24 11:40:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 24 Jul 2018 11:40:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3045) JTA CDI regression (or Standalone JTA 1.2 Quickstart failure) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3045: ----------------------------------- Priority: Critical (was: Major) > JTA CDI regression (or Standalone JTA 1.2 Quickstart failure) > ------------------------------------------------------------- > > Key: JBTM-3045 > URL: https://issues.jboss.org/browse/JBTM-3045 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > The recent changes to our JTA CDI support (https://issues.jboss.org/browse/JBTM-3044) have either caused a regression or the Standalone JTA 1.2 Quickstart needs updating. The failure is: > {quote} > testMandatoryTransactionWithExistingTransaction(org.jboss.narayana.quickstarts.jta.TestCase) Time elapsed: 0.536 sec <<< ERROR! > javax.enterprise.inject.CreationException: Not a compound name: TransactionManager > {quote} > See for example CI run http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-quickstarts/159/console > If the issue does turn out to be a regression then the priority needs to be marked as Critical. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jul 24 14:14:00 2018 From: issues at jboss.org (Laird Nelson (JIRA)) Date: Tue, 24 Jul 2018 14:14:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3045) JTA CDI regression (or Standalone JTA 1.2 Quickstart failure) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13610009#comment-13610009 ] Laird Nelson commented on JBTM-3045: ------------------------------------ The root cause is understood. This is not a regression. Briefly, the JBoss {{NamingContext}} class as used indirectly by the quickstart incorrectly expects that all {{Name}} instances supplied to, for example, {{lookup(Name)}} be {{CompoundName}} instances. The {{TransactionExtension}} class correctly (from the point of the JNDI specification) uses a {{CompositeName}} to lookup {{java:/TransactionManager}}, but the JBoss {{NamingContext}} rejects it because it is not a {{CompoundName}}. The workaround will be for the {{TransactionExtension}} class to supply a {{String}} ("{{java:/TransactionManager}}") instead of a hand-built {{CompositeName}}. Then non-compliant {{InitialContext}} implementations will continue to work as well as compliant ones. > JTA CDI regression (or Standalone JTA 1.2 Quickstart failure) > ------------------------------------------------------------- > > Key: JBTM-3045 > URL: https://issues.jboss.org/browse/JBTM-3045 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > The recent changes to our JTA CDI support (https://issues.jboss.org/browse/JBTM-3044) have either caused a regression or the Standalone JTA 1.2 Quickstart needs updating. The failure is: > {quote} > testMandatoryTransactionWithExistingTransaction(org.jboss.narayana.quickstarts.jta.TestCase) Time elapsed: 0.536 sec <<< ERROR! > javax.enterprise.inject.CreationException: Not a compound name: TransactionManager > {quote} > See for example CI run http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-quickstarts/159/console > If the issue does turn out to be a regression then the priority needs to be marked as Critical. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jul 24 14:24:00 2018 From: issues at jboss.org (Laird Nelson (JIRA)) Date: Tue, 24 Jul 2018 14:24:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3045) JTA CDI regression (or Standalone JTA 1.2 Quickstart failure) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Laird Nelson created pull request #1350 in GitHub ------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > JTA CDI regression (or Standalone JTA 1.2 Quickstart failure) > ------------------------------------------------------------- > > Key: JBTM-3045 > URL: https://issues.jboss.org/browse/JBTM-3045 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > The recent changes to our JTA CDI support (https://issues.jboss.org/browse/JBTM-3044) have either caused a regression or the Standalone JTA 1.2 Quickstart needs updating. The failure is: > {quote} > testMandatoryTransactionWithExistingTransaction(org.jboss.narayana.quickstarts.jta.TestCase) Time elapsed: 0.536 sec <<< ERROR! > javax.enterprise.inject.CreationException: Not a compound name: TransactionManager > {quote} > See for example CI run http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-quickstarts/159/console > If the issue does turn out to be a regression then the priority needs to be marked as Critical. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Jul 24 14:46:00 2018 From: issues at jboss.org (Laird Nelson (JIRA)) Date: Tue, 24 Jul 2018 14:46:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3045) JTA CDI regression (or Standalone JTA 1.2 Quickstart failure) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13610030#comment-13610030 ] Laird Nelson commented on JBTM-3045: ------------------------------------ Pull request filed: https://github.com/jbosstm/narayana/pull/1351 > JTA CDI regression (or Standalone JTA 1.2 Quickstart failure) > ------------------------------------------------------------- > > Key: JBTM-3045 > URL: https://issues.jboss.org/browse/JBTM-3045 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > The recent changes to our JTA CDI support (https://issues.jboss.org/browse/JBTM-3044) have either caused a regression or the Standalone JTA 1.2 Quickstart needs updating. The failure is: > {quote} > testMandatoryTransactionWithExistingTransaction(org.jboss.narayana.quickstarts.jta.TestCase) Time elapsed: 0.536 sec <<< ERROR! > javax.enterprise.inject.CreationException: Not a compound name: TransactionManager > {quote} > See for example CI run http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana-quickstarts/159/console > If the issue does turn out to be a regression then the priority needs to be marked as Critical. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Jul 25 09:24:00 2018 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Wed, 25 Jul 2018 09:24: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 ] Issue was automatically transitioned when Tom Jenkinson created pull request #232 in GitHub ------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > 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 Jul 26 05:55:01 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 26 Jul 2018 05:55:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3043) REST-AT to JTA Bridge Quickstart failing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3043: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > REST-AT to JTA Bridge Quickstart failing > ---------------------------------------- > > Key: JBTM-3043 > URL: https://issues.jboss.org/browse/JBTM-3043 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Critical > Fix For: 5.next > > > ------------------------------------------------------- > Running org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest > Tests run: 4, Failures: 4, Errors: 0, Skipped: 0, Time elapsed: 6.973 sec <<< FAILURE! - in org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest > testCommitWithTwoTasks(org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest) Time elapsed: 0.8 sec <<< FAILURE! > java.lang.AssertionError: expected:<201> but was:<500> > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.createTask(TaskResourceTest.java:190) > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.testCommitWithTwoTasks(TaskResourceTest.java:147) > testRollback(org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest) Time elapsed: 0.094 sec <<< FAILURE! > java.lang.AssertionError: expected:<201> but was:<500> > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.createTask(TaskResourceTest.java:190) > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.testRollback(TaskResourceTest.java:130) > testCommit(org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest) Time elapsed: 0.066 sec <<< FAILURE! > java.lang.AssertionError: expected:<201> but was:<500> > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.createTask(TaskResourceTest.java:190) > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.testCommit(TaskResourceTest.java:111) > testRollbackWithTwoTasks(org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest) Time elapsed: 0.063 sec <<< FAILURE! > java.lang.AssertionError: expected:<201> but was:<500> > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.createTask(TaskResourceTest.java:190) > at org.jboss.narayana.quickstart.rest.bridge.inbound.jpa.test.TaskResourceTest.testRollbackWithTwoTasks(TaskResourceTest.java:169) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 26 07:37:00 2018 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 26 Jul 2018 07:37:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2847) Static code analysis - check report and fix issues In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13610917#comment-13610917 ] Ondra Chaloupka commented on JBTM-2847: --------------------------------------- additional static analysis refactoring at PR: https://github.com/jbosstm/narayana/pull/1349 > Static code analysis - check report and fix issues > -------------------------------------------------- > > Key: JBTM-2847 > URL: https://issues.jboss.org/browse/JBTM-2847 > Project: JBoss Transaction Manager > Issue Type: Task > Affects Versions: 5.5.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.5.2.Final > > > By going through static code analysis report of changes done during last a half year there are few issues that would be fine to be adjusted. > They are following > # at com.arjuna.ats.internal.jta.transaction.arjunacore.jca.XATerminatorImple, > L614; com.arjuna.ats.internal.jta.transaction.jts.jca, L471 > (https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com/arjuna/ats/internal/jta/transaction/arjunacore/jca/XATerminatorImple.java#L614) the calling method getCurrentTransactionId() potentially could end with > NullPointerException (caused by TransactionImple#getTransaction when `final BasicAction current = BasicAction.Current()` is null) > # possible resource leak - connection was ommitted to be closed > ## org.jboss.narayana.tomcat.jta.integration.TestExecutor > ## TestCommitMarkableResourceFailAfterCommitOrphan > # inner class SampleLockable of org.jboss.stm.STMVerticle could be static (http://station5.brq.redhat.com:8080/docs/en/findbugs/fb_checker_ref.html#FB.SIC_INNER_SHOULD_BE_STATIC) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 26 07:38:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 26 Jul 2018 07:38:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3046) REST-AT PerformanceTest occasionally hangs on Windows CI runs In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-3046: -------------------------------------- Summary: REST-AT PerformanceTest occasionally hangs on Windows CI runs Key: JBTM-3046 URL: https://issues.jboss.org/browse/JBTM-3046 Project: JBoss Transaction Manager Issue Type: Bug Components: Performance Testing Affects Versions: 5.9.0.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The test runs from the rts/at/tx/pom.xml module (org.jboss.narayana.rts:restat). The hanging thread seems to be a coordinator request to start an inVM REST-AT transaction. The coordinator is running in an Undertow container and the failing test is org.jboss.jbossts.star.test.PerformanceTest See the attachment for the stacktraces. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 26 07:40:01 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 26 Jul 2018 07:40:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3046) REST-AT PerformanceTest occasionally hangs on Windows CI runs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-3046: ----------------------------------- Attachment: threaddump.txt > REST-AT PerformanceTest occasionally hangs on Windows CI runs > ------------------------------------------------------------- > > Key: JBTM-3046 > URL: https://issues.jboss.org/browse/JBTM-3046 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > Attachments: threaddump.txt > > > The test runs from the rts/at/tx/pom.xml module (org.jboss.narayana.rts:restat). The hanging thread seems to be a coordinator request to start an inVM REST-AT transaction. The coordinator is running in an Undertow container and the failing test is org.jboss.jbossts.star.test.PerformanceTest > See the attachment for the stacktraces. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 26 07:43:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 26 Jul 2018 07:43:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3046) REST-AT PerformanceTest occasionally hangs on Windows CI runs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1352 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > REST-AT PerformanceTest occasionally hangs on Windows CI runs > ------------------------------------------------------------- > > Key: JBTM-3046 > URL: https://issues.jboss.org/browse/JBTM-3046 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > Attachments: threaddump.txt > > > The test runs from the rts/at/tx/pom.xml module (org.jboss.narayana.rts:restat). The hanging thread seems to be a coordinator request to start an inVM REST-AT transaction. The coordinator is running in an Undertow container and the failing test is org.jboss.jbossts.star.test.PerformanceTest > See the attachment for the stacktraces. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Jul 26 12:16:00 2018 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 26 Jul 2018 12:16:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-3046) REST-AT PerformanceTest occasionally hangs on Windows CI runs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-3046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13611237#comment-13611237 ] Michael Musgrove commented on JBTM-3046: ---------------------------------------- The linked pull request upgrades the version of Undertow used for running the test. > REST-AT PerformanceTest occasionally hangs on Windows CI runs > ------------------------------------------------------------- > > Key: JBTM-3046 > URL: https://issues.jboss.org/browse/JBTM-3046 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Performance Testing > Affects Versions: 5.9.0.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > Attachments: threaddump.txt > > > The test runs from the rts/at/tx/pom.xml module (org.jboss.narayana.rts:restat). The hanging thread seems to be a coordinator request to start an inVM REST-AT transaction. The coordinator is running in an Undertow container and the failing test is org.jboss.jbossts.star.test.PerformanceTest > See the attachment for the stacktraces. -- This message was sent by Atlassian JIRA (v7.5.0#75005)