From issues at jboss.org Thu Nov 2 04:16:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 2 Nov 2017 04:16:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2951) Application using LRAClient starts with multiple warnings In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2951: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done For client filters removed the {{@Provider}} annotation and left only initialization via descriptors. > Application using LRAClient starts with multiple warnings > --------------------------------------------------------- > > Key: JBTM-2951 > URL: https://issues.jboss.org/browse/JBTM-2951 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > When starting an application using {{LRAClient}} I get several warnings during startup > {code} > 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRARequestFilter is already registered. 2nd registration is being ignored. > 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRAResponseFilter is already registered. 2nd registration is being ignored. > 2017-10-30 08:25:34,551 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ServerLRAFilter is already registered. 2nd registration is being ignored. > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Nov 2 04:16:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 2 Nov 2017 04:16:00 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2950) LRA logging is wrong in pointing to tsLogger and using System.out In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2950: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > LRA logging is wrong in pointing to tsLogger and using System.out > ----------------------------------------------------------------- > > Key: JBTM-2950 > URL: https://issues.jboss.org/browse/JBTM-2950 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > The LRA module uses inconsistent way of logging. Some parts uses the {{com.arjuna.ats.arjuna.logging}} which is wrong as it should define its own logger category to use in LRA. Other ones uses {{System.out|err}} for printing log information. > Up to that there should be more consistency and more informative for user. > * There are hidden reasons of some failures in some places. > * The error messages get from the URL queries are unclear in some cases, e.g. > {{not present: null: Cannont connect to an LRA coordinator: Connection refused}} > (what does means {{not present}} and why {{null}}? this is a bit misguiding info which is not necessary to be part of the error message) -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Nov 2 04:16:01 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 2 Nov 2017 04:16:01 -0400 (EDT) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2952) LRA rest cdi checker should not demand @Status In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2952: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > LRA rest cdi checker should not demand @Status > ---------------------------------------------- > > Key: JBTM-2952 > URL: https://issues.jboss.org/browse/JBTM-2952 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > > The LRA cdi checker expects the `@Status` annotation being compulsory for LRA annotated class. That is not true and `@Status` is not required. > In addition it would be good to consider check for async completion (usage of `@Suspended`) where `@Status` is in contrary expected. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Nov 5 04:14:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Sun, 5 Nov 2017 04:14:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2124) Add orphan detection for JTS interposition mode In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485932#comment-13485932 ] Tom Jenkinson commented on JBTM-2124: ------------------------------------- You would need to consider orphan detection for JTS where we have an imported JCA transaction as that does not allow us to mutate the Xid so we can't do a check for orphaned XAResource > Add orphan detection for JTS interposition mode > ----------------------------------------------- > > Key: JBTM-2124 > URL: https://issues.jboss.org/browse/JBTM-2124 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Recovery > Affects Versions: 4.17.17 > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.later > > > Currently orphan detection is supported for JTA, not for JTS. Please, add the suport for JTS as well. > The following scenario for JTS causes that the orphan is left in the transaction log store and the prepared resource could held the lock till the time that it's timeouted on the side of the database/jms. > The program flow is following (test run on EAP 6) > enlisting jms xaresource to transaction > sending msg to queue > enlisting xa test resource > preparing jms xaresource > preparing xa test resource > crash JVM at the end of the test XAResource.prepare() > restart app server and recovery is run > During recovery the jms resource is processed correctly because TM found some info in its jts logs. But such info was not saved for test xa resource. The test xa is not rollback. > More info and discussion could be found at: https://bugzilla.redhat.com/show_bug.cgi?id=1064170 -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Sun Nov 5 12:36:00 2017 From: issues at jboss.org (Mark Little (JIRA)) Date: Sun, 5 Nov 2017 12:36:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2949) Remove synchronization from ThreadUtil.getThreadId In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13485944#comment-13485944 ] Mark Little commented on JBTM-2949: ----------------------------------- I agree with Mike and Tom. Would be good to understand how much of an overhead the current implementation represents first. > Remove synchronization from ThreadUtil.getThreadId > -------------------------------------------------- > > Key: JBTM-2949 > URL: https://issues.jboss.org/browse/JBTM-2949 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Luis Barreiro > > JBTM-2808 adds synchronization on {{ThreadUtil.getThreadId()}} but that solution does not scale well enough under high contention. > There seems to be ways to remove this synchronization: > # *ConcurrentWeakHashMap* - replace the current {{WeakHashMap}} for a similar data structure that can handle concurrent access. This keeps the same behavior. > # *Use Thread.getId()* - remove all mappings and generate the {{threadId}} from the {{Thread}}. Although the javadoc mentions that IDs can be reused, the implementation is a counter, like what {{ThreadUtil}} has now. This is the simplest and most elegant fix. > # *Remove {{threadId}}* - remove the generation of {{threadId}} and use the {{Thread}} throughout the code, generating string IDs when necessary. Probably yields the best performance, but requires the most changes. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 6 04:39:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 6 Nov 2017 04:39:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2954: ------------------------------------- Summary: LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 Key: JBTM-2954 URL: https://issues.jboss.org/browse/JBTM-2954 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.7.1.Final Reporter: Ondra Chaloupka Assignee: Michael Musgrove If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. {code} WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] {code} The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("{LraId}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. {code} HTTP/1.1 200 OK Connection: keep-alive Content-Type: application/json Content-Length: 359 Date: Mon, 06 Nov 2017 09:14:44 GMT {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} {code} Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 6 04:40:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 6 Nov 2017 04:40:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13486066#comment-13486066 ] Ondra Chaloupka commented on JBTM-2954: --------------------------------------- [~mmusgrov] I assigned to you as I'm not sure about the correct functionality. If you tell me how it should work I can prepare the fix. > LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2954 > URL: https://issues.jboss.org/browse/JBTM-2954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > > If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. > {code} > WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] > {code} > The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("{LraId}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. > If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. > I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. > {code} > HTTP/1.1 200 OK > Connection: keep-alive > Content-Type: application/json > Content-Length: 359 > Date: Mon, 06 Nov 2017 09:14:44 GMT > {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} > {code} > Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 6 04:41:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 6 Nov 2017 04:41:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2954: ---------------------------------- Description: If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. {code} WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] {code} The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. {code} HTTP/1.1 200 OK Connection: keep-alive Content-Type: application/json Content-Length: 359 Date: Mon, 06 Nov 2017 09:14:44 GMT {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} {code} Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. was: If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. {code} WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] {code} The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("{LraId}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. {code} HTTP/1.1 200 OK Connection: keep-alive Content-Type: application/json Content-Length: 359 Date: Mon, 06 Nov 2017 09:14:44 GMT {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} {code} Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. > LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2954 > URL: https://issues.jboss.org/browse/JBTM-2954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > > If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. > {code} > WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] > {code} > The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. > If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. > I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. > {code} > HTTP/1.1 200 OK > Connection: keep-alive > Content-Type: application/json > Content-Length: 359 > Date: Mon, 06 Nov 2017 09:14:44 GMT > {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} > {code} > Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Nov 7 11:47:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 7 Nov 2017 11:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2955) Add a filter that checks for running subordinate transactions before identifying a branch as orphaned In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2955: ----------------------------------- Summary: Add a filter that checks for running subordinate transactions before identifying a branch as orphaned Key: JBTM-2955 URL: https://issues.jboss.org/browse/JBTM-2955 Project: JBoss Transaction Manager Issue Type: Enhancement Components: JTA Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next It is possible that when a transaction is propagated to another JVM using EJB remoting (which uses the SubordinationManager for importing a TX) and it is slow to prepare orphan detection may rollback one of its previously prepared XAResources. We can detect if a subordinate TX is already running for a gtrid so we can use that. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Nov 9 09:53:04 2017 From: issues at jboss.org (Luis Barreiro (JIRA)) Date: Thu, 9 Nov 2017 09:53:04 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2949) Remove synchronization from ThreadUtil.getThreadId In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luis Barreiro updated JBTM-2949: -------------------------------- Attachment: specj_349Q.png > Remove synchronization from ThreadUtil.getThreadId > -------------------------------------------------- > > Key: JBTM-2949 > URL: https://issues.jboss.org/browse/JBTM-2949 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Luis Barreiro > Attachments: specj_349Q.png > > > JBTM-2808 adds synchronization on {{ThreadUtil.getThreadId()}} but that solution does not scale well enough under high contention. > There seems to be ways to remove this synchronization: > # *ConcurrentWeakHashMap* - replace the current {{WeakHashMap}} for a similar data structure that can handle concurrent access. This keeps the same behavior. > # *Use Thread.getId()* - remove all mappings and generate the {{threadId}} from the {{Thread}}. Although the javadoc mentions that IDs can be reused, the implementation is a counter, like what {{ThreadUtil}} has now. This is the simplest and most elegant fix. > # *Remove {{threadId}}* - remove the generation of {{threadId}} and use the {{Thread}} throughout the code, generating string IDs when necessary. Probably yields the best performance, but requires the most changes. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Nov 10 02:56:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 10 Nov 2017 02:56:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2956) Add a simple pooling datasource wrapper In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2956: ----------------------------------- Summary: Add a simple pooling datasource wrapper Key: JBTM-2956 URL: https://issues.jboss.org/browse/JBTM-2956 Project: JBoss Transaction Manager Issue Type: Task Components: Testing Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next Due to move to containerized databases we see that some of the databases can be somewhat constrained with transient connection failures. We can alleviate that slightly with a simple pooling wrapper. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Nov 10 03:22:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 10 Nov 2017 03:22:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2949) Remove synchronization from ThreadUtil.getThreadId In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488532#comment-13488532 ] Tom Jenkinson commented on JBTM-2949: ------------------------------------- I will update our regression checker to see if we can replicate with 10x cores thread count > Remove synchronization from ThreadUtil.getThreadId > -------------------------------------------------- > > Key: JBTM-2949 > URL: https://issues.jboss.org/browse/JBTM-2949 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Luis Barreiro > Attachments: specj_349Q.png > > > JBTM-2808 adds synchronization on {{ThreadUtil.getThreadId()}} but that solution does not scale well enough under high contention. > There seems to be ways to remove this synchronization: > # *ConcurrentWeakHashMap* - replace the current {{WeakHashMap}} for a similar data structure that can handle concurrent access. This keeps the same behavior. > # *Use Thread.getId()* - remove all mappings and generate the {{threadId}} from the {{Thread}}. Although the javadoc mentions that IDs can be reused, the implementation is a counter, like what {{ThreadUtil}} has now. This is the simplest and most elegant fix. > # *Remove {{threadId}}* - remove the generation of {{threadId}} and use the {{Thread}} throughout the code, generating string IDs when necessary. Probably yields the best performance, but requires the most changes. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Nov 10 09:40:01 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 10 Nov 2017 09:40:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488798#comment-13488798 ] Michael Musgrove commented on JBTM-2954: ---------------------------------------- Both methods should behave almost identically, the only difference being the media type of the response body (plain text versus JSON) as defined according by the @Produces tag. If we make sure that the detail status method also does returns Response.noContent().build(); if the LRA is still "active" just like the plain text version then would that be sufficient to fix this issue? > LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2954 > URL: https://issues.jboss.org/browse/JBTM-2954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > > If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. > {code} > WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] > {code} > The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. > If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. > I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. > {code} > HTTP/1.1 200 OK > Connection: keep-alive > Content-Type: application/json > Content-Length: 359 > Date: Mon, 06 Nov 2017 09:14:44 GMT > {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} > {code} > Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Nov 10 09:50:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Fri, 10 Nov 2017 09:50:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488815#comment-13488815 ] Ondra Chaloupka commented on JBTM-2954: --------------------------------------- The issue consists two parts First is the WARNING in the log, shown by the REST EASY (`WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods`, which I think is not necessary to have. It's about creation one REST endpoind and let it handled programatically based on the accept header content what type of the response is returned. The second part is about different status being returned. That way the fix of having both methods (or both implementations) returning the `Response.noContent().build()` will fix the thing (plus adjusting javadoc and comments appropriately). Well , with info from your comment I can prepare the fix now, if you don't mind, and you can then validate if it's ok. > LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2954 > URL: https://issues.jboss.org/browse/JBTM-2954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > > If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. > {code} > WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] > {code} > The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. > If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. > I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. > {code} > HTTP/1.1 200 OK > Connection: keep-alive > Content-Type: application/json > Content-Length: 359 > Date: Mon, 06 Nov 2017 09:14:44 GMT > {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} > {code} > Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 13 02:32:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 13 Nov 2017 02:32:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2954: ---------------------------------- Steps to Reproduce: Start lra coordinator, use the curl to simulate {code} curl -i -X POST http://localhost:8080/lra-coordinator/start curl -i -X GET http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f curl -i -X GET -H "Accept=application/json" http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f curl -i -X GET -H "Accept: text/plain" http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f {code} was: Start lra coordinator, use the curl to simulate {code} curl -i -X POST http://localhost:8080/start curl -i -X GET http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f curl -i -X GET -H "Accept=application/json" http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f curl -i -X GET -H "Accept: text/plain" http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f {code} > LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2954 > URL: https://issues.jboss.org/browse/JBTM-2954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > > If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. > {code} > WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] > {code} > The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. > If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. > I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. > {code} > HTTP/1.1 200 OK > Connection: keep-alive > Content-Type: application/json > Content-Length: 359 > Date: Mon, 06 Nov 2017 09:14:44 GMT > {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} > {code} > Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 13 05:56:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 13 Nov 2017 05:56:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489260#comment-13489260 ] Ondra Chaloupka commented on JBTM-2954: --------------------------------------- hi [~mmusgrov], my idea of the fix is here: https://github.com/ochaloup/narayana/commit/30d4f36ba9d2216ed25fb7bc7fe306ba51a557f8 It consists from points * lra status is merged to one method where based on the header the response is returned - that's how the WARNING is ommitted * status from the {{Transaction}} is changed to be {{204}} and not {{202}} in case of the LRA is still available * the behaviour for the {{application/json}} was changed - in case LRA is active previously http return code {{200}} with json referring to status was returned, now the {{204}} referring to the status is returned Could be checke with curl calls {code} curl -i -X POST http://127.0.0.1:8080/lra-coordinator/start curl -i -X GET -H "Accept: text/xml" http://localhost:8080/lra-coordinator/0_ffff0a000007_-4bbc6a89_5a097341_f HTTP/1.1 406 Not Acceptable curl -i -X GET -H "Accept: application/json" http://localhost:8080/lra-coordinator/0_ffff0a000007_-4bbc6a89_5a097341_f HTTP/1.1 406 Not Acceptable curl -i -X PUT -H "Link: http://localhost" http://localhost:8080/lra-coordinator/0_ffff0a000007_-4bbc6a89_5a097341_f 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_-4bbc6a89_5a097341_f/0_ffff0a000007_-4bbc6a89_5a097341_18 Location: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8080%2Flra-coordinator%2F0_ffff0a000007_-4bbc6a89_5a097341_f/0_ffff0a000007_-4bbc6a89_5a097341_18 curl -i -X PUT http://localhost:8080/lra-coordinator/0_ffff0a000007_-4bbc6a89_5a097341_f/close HTTP/1.1 200 OK Connection: keep-alive Long-Running-Action: http://localhost:8080/lra-coordinator/0_ffff0a000007_-4bbc6a89_5a097341_f {code} now status is shown {code} curl -i -X GET -H "Accept: text/*" http://localhost:8080/lra-coordinator/0_ffff0a000007_-4bbc6a89_5a097341_f HTTP/1.1 200 OK Connection: keep-alive Content-Type: text/plain Content-Length: 12 Date: Mon, 13 Nov 2017 10:33:13 GMT Compensating {code} and {code} curl -i -X GET -H "Accept: application/*" http://localhost:8080/lra-coordinator/0_ffff0a000007_-4bbc6a89_5a097341_f HTTP/1.1 200 OK Connection: keep-alive Content-Type: application/json Content-Length: 385 Date: Mon, 13 Nov 2017 10:33:03 GMT {"lraId":"http://127.0.0.1:8080/lra-coordinator/0_ffff0a000007_-4bbc6a89_5a097341_f","clientId":"","httpStatus":200,"responseData":"Compensating","status":"Compensating","recovering":true,"compensating":true,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"completing":false,"encodedResponseData":"Compensating","topLevel":true,"active":false,"completed":false} {code} What do you think? > LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2954 > URL: https://issues.jboss.org/browse/JBTM-2954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > > If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. > {code} > WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] > {code} > The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. > If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. > I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. > {code} > HTTP/1.1 200 OK > Connection: keep-alive > Content-Type: application/json > Content-Length: 359 > Date: Mon, 06 Nov 2017 09:14:44 GMT > {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} > {code} > Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 13 06:00:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 13 Nov 2017 06:00:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489264#comment-13489264 ] Michael Musgrove commented on JBTM-2954: ---------------------------------------- I am not sure what you mean about the WARNING - if the client does not specify an accept header then he can expect to receive a response in any of the formats supported by the resource. But I do agree that it would be best to return MediaType.TEXT_PLAIN. Can you raise a PR so I can see what you have in mind. > LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2954 > URL: https://issues.jboss.org/browse/JBTM-2954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Michael Musgrove > > If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. > {code} > WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] > {code} > The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. > If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. > I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. > {code} > HTTP/1.1 200 OK > Connection: keep-alive > Content-Type: application/json > Content-Length: 359 > Date: Mon, 06 Nov 2017 09:14:44 GMT > {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} > {code} > Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 13 06:04:01 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 13 Nov 2017 06:04:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reassigned JBTM-2954: -------------------------------------- Assignee: Ondra Chaloupka (was: Michael Musgrove) > LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2954 > URL: https://issues.jboss.org/browse/JBTM-2954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. > {code} > WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] > {code} > The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. > If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. > I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. > {code} > HTTP/1.1 200 OK > Connection: keep-alive > Content-Type: application/json > Content-Length: 359 > Date: Mon, 06 Nov 2017 09:14:44 GMT > {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} > {code} > Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 13 06:11:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 13 Nov 2017 06:11:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489273#comment-13489273 ] Michael Musgrove commented on JBTM-2954: ---------------------------------------- Your solution is adding a lot of code complexity for what is in fact a sloppily written client. If the client says what content he is prepared to accept then he will get the response in a predictable format. > LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2954 > URL: https://issues.jboss.org/browse/JBTM-2954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. > {code} > WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] > {code} > The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. > If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. > I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. > {code} > HTTP/1.1 200 OK > Connection: keep-alive > Content-Type: application/json > Content-Length: 359 > Date: Mon, 06 Nov 2017 09:14:44 GMT > {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} > {code} > Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 13 06:21:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 13 Nov 2017 06:21:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489273#comment-13489273 ] Michael Musgrove edited comment on JBTM-2954 at 11/13/17 6:20 AM: ------------------------------------------------------------------ Your solution is adding a lot of code complexity for what is in fact a sloppily written client. If the client says what content he is prepared to accept then he will get the response in a predictable format. Note also that content negotiation is one of the core principles of REST so the client will/should be well aware of his responsibilities. If he isn't aware of those principles then the WARNING provides him with an opportunity to learn about content negotiation. was (Author: mmusgrov): Your solution is adding a lot of code complexity for what is in fact a sloppily written client. If the client says what content he is prepared to accept then he will get the response in a predictable format. > LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2954 > URL: https://issues.jboss.org/browse/JBTM-2954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. > {code} > WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] > {code} > The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. > If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. > I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. > {code} > HTTP/1.1 200 OK > Connection: keep-alive > Content-Type: application/json > Content-Length: 359 > Date: Mon, 06 Nov 2017 09:14:44 GMT > {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} > {code} > Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 13 06:32:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 13 Nov 2017 06:32:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Ondra Chaloupka created pull request #1251 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2954 > URL: https://issues.jboss.org/browse/JBTM-2954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. > {code} > WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] > {code} > The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. > If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. > I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. > {code} > HTTP/1.1 200 OK > Connection: keep-alive > Content-Type: application/json > Content-Length: 359 > Date: Mon, 06 Nov 2017 09:14:44 GMT > {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} > {code} > Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 13 06:33:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 13 Nov 2017 06:33:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489287#comment-13489287 ] Ondra Chaloupka commented on JBTM-2954: --------------------------------------- My main reproach was that lra coordinator shows warnings in the server.log with content: {code} RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] {code} this is caused by the fact that two methods are bound to the same REST endpoint. This happens when client does not specify the {{Accept}} header which matches the method signature. But I agree, I got to the end of too complex code. That's wrong. If client does not specify the header the warning seems to be navoidable (at least I haven't found a nice solution to get rid of it) Proposing only a fix for status code: https://github.com/jbosstm/narayana/pull/1251 > LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2954 > URL: https://issues.jboss.org/browse/JBTM-2954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. > {code} > WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] > {code} > The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. > If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. > I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. > {code} > HTTP/1.1 200 OK > Connection: keep-alive > Content-Type: application/json > Content-Length: 359 > Date: Mon, 06 Nov 2017 09:14:44 GMT > {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} > {code} > Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 13 06:33:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 13 Nov 2017 06:33:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489287#comment-13489287 ] Ondra Chaloupka edited comment on JBTM-2954 at 11/13/17 6:32 AM: ----------------------------------------------------------------- [~mmusgrov] My main reproach was that lra coordinator shows warnings in the server.log with content: {code} RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] {code} this is caused by the fact that two methods are bound to the same REST endpoint. This happens when client does not specify the {{Accept}} header which matches the method signature. But I agree, I got to the end of too complex code. That's wrong. If client does not specify the header the warning seems to be navoidable (at least I haven't found a nice solution to get rid of it) Proposing only a fix for status code: https://github.com/jbosstm/narayana/pull/1251 was (Author: ochaloup): My main reproach was that lra coordinator shows warnings in the server.log with content: {code} RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] {code} this is caused by the fact that two methods are bound to the same REST endpoint. This happens when client does not specify the {{Accept}} header which matches the method signature. But I agree, I got to the end of too complex code. That's wrong. If client does not specify the header the warning seems to be navoidable (at least I haven't found a nice solution to get rid of it) Proposing only a fix for status code: https://github.com/jbosstm/narayana/pull/1251 > LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2954 > URL: https://issues.jboss.org/browse/JBTM-2954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. > {code} > WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] > {code} > The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. > If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. > I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. > {code} > HTTP/1.1 200 OK > Connection: keep-alive > Content-Type: application/json > Content-Length: 359 > Date: Mon, 06 Nov 2017 09:14:44 GMT > {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} > {code} > Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 13 06:34:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 13 Nov 2017 06:34:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489287#comment-13489287 ] Ondra Chaloupka edited comment on JBTM-2954 at 11/13/17 6:33 AM: ----------------------------------------------------------------- [~mmusgrov] My main reproach was that lra coordinator shows warnings in the server.log with content: {code} RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] {code} this is caused by the fact that two methods are bound to the same REST endpoint. This happens when client does not specify the {{Accept}} header which matches the method signature. But I agree, I got to the end of too complex code. That's wrong. If client does not specify the header the warning seems to be unavoidable (at least I haven't found a nice solution to get rid of it) Proposing only a fix for status code: https://github.com/jbosstm/narayana/pull/1251 was (Author: ochaloup): [~mmusgrov] My main reproach was that lra coordinator shows warnings in the server.log with content: {code} RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] {code} this is caused by the fact that two methods are bound to the same REST endpoint. This happens when client does not specify the {{Accept}} header which matches the method signature. But I agree, I got to the end of too complex code. That's wrong. If client does not specify the header the warning seems to be navoidable (at least I haven't found a nice solution to get rid of it) Proposing only a fix for status code: https://github.com/jbosstm/narayana/pull/1251 > LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2954 > URL: https://issues.jboss.org/browse/JBTM-2954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. > {code} > WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] > {code} > The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. > If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. > I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. > {code} > HTTP/1.1 200 OK > Connection: keep-alive > Content-Type: application/json > Content-Length: 359 > Date: Mon, 06 Nov 2017 09:14:44 GMT > {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} > {code} > Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 13 06:41:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 13 Nov 2017 06:41:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2957) LRA spec start and finish descriptions do not specify HTTP status codes In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2957: -------------------------------------- Summary: LRA spec start and finish descriptions do not specify HTTP status codes Key: JBTM-2957 URL: https://issues.jboss.org/browse/JBTM-2957 Project: JBoss Transaction Manager Issue Type: Enhancement Components: LRA Affects Versions: 5.7.1.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.later The specification does not specify the HTTP response codes for starting and ending LRAs. The [relevant sections of the specification|https://github.com/eclipse/microprofile-sandbox/blob/master/proposals/0009-LRA/README.md#protocol-urls] are: > Performing a `POST` on ... creates an LRA. > Performing a `PUT` on .../close will trigger the successful completion of the LRA ... This means that it is vague as to whether asynchronous operations are supported, which they should be (since the target use case for LRAs is a microservice based environment). The proposal should be updated to include the response codes and it SHOULD include the ability to return "202 Accepted" -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 13 06:43:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 13 Nov 2017 06:43:00 -0500 (EST) 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: Ondra Chaloupka created JBTM-2958: ------------------------------------- Summary: 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 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 Mon Nov 13 08:19:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 13 Nov 2017 08:19:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2957) LRA spec start and finish descriptions do not specify HTTP status codes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489335#comment-13489335 ] Michael Musgrove commented on JBTM-2957: ---------------------------------------- Both LRA and LRA participant lifecycle operations need to support asynchronicity (ie 202 Accepted response status codes should be valid). > LRA spec start and finish descriptions do not specify HTTP status codes > ----------------------------------------------------------------------- > > Key: JBTM-2957 > URL: https://issues.jboss.org/browse/JBTM-2957 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > The specification does not specify the HTTP response codes for starting and ending LRAs. The [relevant sections of the specification|https://github.com/eclipse/microprofile-sandbox/blob/master/proposals/0009-LRA/README.md#protocol-urls] are: > > Performing a `POST` on ... creates an LRA. > > Performing a `PUT` on .../close will trigger the successful completion of the LRA ... > This means that it is vague as to whether asynchronous operations are supported, which they should be (since the target use case for LRAs is a microservice based environment). > The proposal should be updated to include the response codes and it SHOULD include the ability to return "202 Accepted" -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 13 11:13:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 13 Nov 2017 11:13:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2959) Allow different LRA coordinators to share an object store In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2959: -------------------------------------- Summary: Allow different LRA coordinators to share an object store Key: JBTM-2959 URL: https://issues.jboss.org/browse/JBTM-2959 Project: JBoss Transaction Manager Issue Type: Enhancement Components: LRA Affects Versions: 5.7.1.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.later Currently each LRA coordinator (the component responsible for starting and managing LRAs) needs its own object store. This can cause problems in dynamic environments where nodes come and go. If we embed the node id in the id for an LRA then we can relax this restriction (ie different coordinators can share a store). This change will also mean that a single recovery manager can recover LRAs for multiple nodes. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 13 11:20:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 13 Nov 2017 11:20:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2957) LRA specification: descriptions for start/end and LRA do not say which response codes are valid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2957: ----------------------------------- Summary: LRA specification: descriptions for start/end and LRA do not say which response codes are valid (was: LRA spec start and finish descriptions do not specify HTTP status codes) > LRA specification: descriptions for start/end and LRA do not say which response codes are valid > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2957 > URL: https://issues.jboss.org/browse/JBTM-2957 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > The specification does not specify the HTTP response codes for starting and ending LRAs. The [relevant sections of the specification|https://github.com/eclipse/microprofile-sandbox/blob/master/proposals/0009-LRA/README.md#protocol-urls] are: > > Performing a `POST` on ... creates an LRA. > > Performing a `PUT` on .../close will trigger the successful completion of the LRA ... > This means that it is vague as to whether asynchronous operations are supported, which they should be (since the target use case for LRAs is a microservice based environment). > The proposal should be updated to include the response codes and it SHOULD include the ability to return "202 Accepted" -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 13 11:20:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 13 Nov 2017 11:20:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2957) LRA specification: descriptions for start/end and LRA do not say which response codes are valid In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2957: ----------------------------------- Description: The specification does not specify the HTTP response codes for starting and ending LRAs. The [relevant sections of the specification|https://github.com/eclipse/microprofile-sandbox/blob/master/proposals/0009-LRA/README.md#protocol-urls] are: > Performing a `POST` on ... creates an LRA. > Performing a `PUT` on .../close will trigger the successful completion of the LRA ... This means that it is vague as to whether asynchronous operations are supported, which they should be (since the target use case for LRAs is a microservice based environment). The proposal (and reference implementation) should be updated to include the response codes and it SHOULD include the ability to return "202 Accepted" was: The specification does not specify the HTTP response codes for starting and ending LRAs. The [relevant sections of the specification|https://github.com/eclipse/microprofile-sandbox/blob/master/proposals/0009-LRA/README.md#protocol-urls] are: > Performing a `POST` on ... creates an LRA. > Performing a `PUT` on .../close will trigger the successful completion of the LRA ... This means that it is vague as to whether asynchronous operations are supported, which they should be (since the target use case for LRAs is a microservice based environment). The proposal should be updated to include the response codes and it SHOULD include the ability to return "202 Accepted" > LRA specification: descriptions for start/end and LRA do not say which response codes are valid > ----------------------------------------------------------------------------------------------- > > Key: JBTM-2957 > URL: https://issues.jboss.org/browse/JBTM-2957 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > The specification does not specify the HTTP response codes for starting and ending LRAs. The [relevant sections of the specification|https://github.com/eclipse/microprofile-sandbox/blob/master/proposals/0009-LRA/README.md#protocol-urls] are: > > Performing a `POST` on ... creates an LRA. > > Performing a `PUT` on .../close will trigger the successful completion of the LRA ... > This means that it is vague as to whether asynchronous operations are supported, which they should be (since the target use case for LRAs is a microservice based environment). > The proposal (and reference implementation) should be updated to include the response codes and it SHOULD include the ability to return "202 Accepted" -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 13 11:26:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Mon, 13 Nov 2017 11:26:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2959) Allow different LRA coordinators to share an object store In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2959: ----------------------------------- Description: Currently each LRA coordinator (the component responsible for starting and managing LRAs) needs its own object store. This can cause problems in dynamic environments where nodes come and go. If we embed the node id in the id for an LRA then we can relax this restriction (ie different coordinators can share a store). This change will also mean that a single recovery manager can recover LRAs for multiple nodes. Some notes on the current implementation: # You may have multiple coordinators for a single tree of transactions (ie nested LRAs can be managed by a coordinator that is different from the parent). # There can only be one recovery coordinator per store. Note that this [restriction of the implementation] does not impact the spec since the mechanics of recovery is a private matter (ie in the spec we only demand that recovery takes place). # The only user visible aspect of recovery is the "recovery coordinator URL" that participants receive when they enlist with the LRA and the implementation of that endpoint is opaque to the user. # Provided recovery takes place (ie the correct participant endpoints are called in the appropriate way) that is all the use needs to know about recovery. # The administrator can ask for recovering LRAs as follows: `GET {base uri}/lra-coordinator/?status={Completing|Compensated|etc}` returns a subset of all LRAs ... (this is discussed in the spec in the section called "Interoperability with other languages"). was: Currently each LRA coordinator (the component responsible for starting and managing LRAs) needs its own object store. This can cause problems in dynamic environments where nodes come and go. If we embed the node id in the id for an LRA then we can relax this restriction (ie different coordinators can share a store). This change will also mean that a single recovery manager can recover LRAs for multiple nodes. > Allow different LRA coordinators to share an object store > --------------------------------------------------------- > > Key: JBTM-2959 > URL: https://issues.jboss.org/browse/JBTM-2959 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.later > > > Currently each LRA coordinator (the component responsible for starting and managing LRAs) needs its own object store. This can cause problems in dynamic environments where nodes come and go. > If we embed the node id in the id for an LRA then we can relax this restriction (ie different coordinators can share a store). This change will also mean that a single recovery manager can recover LRAs for multiple nodes. > Some notes on the current implementation: > # You may have multiple coordinators for a single tree of transactions (ie nested LRAs can be managed by a coordinator that is different from the parent). > # There can only be one recovery coordinator per store. Note that this [restriction of the implementation] does not impact the spec since the mechanics of recovery is a private matter (ie in the spec we only demand that recovery takes place). > # The only user visible aspect of recovery is the "recovery coordinator URL" that participants receive when they enlist with the LRA and the implementation of that endpoint is opaque to the user. > # Provided recovery takes place (ie the correct participant endpoints are called in the appropriate way) that is all the use needs to know about recovery. > # The administrator can ask for recovering LRAs as follows: `GET {base uri}/lra-coordinator/?status={Completing|Compensated|etc}` returns a subset of all LRAs ... (this is discussed in the spec in the section called "Interoperability with other languages"). -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 13 11:47:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Mon, 13 Nov 2017 11:47:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2955) Add a filter that checks for running subordinate transactions before identifying a branch as orphaned In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson resolved JBTM-2955. --------------------------------- Resolution: Done > Add a filter that checks for running subordinate transactions before identifying a branch as orphaned > ----------------------------------------------------------------------------------------------------- > > Key: JBTM-2955 > URL: https://issues.jboss.org/browse/JBTM-2955 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: JTA > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > It is possible that when a transaction is propagated to another JVM using EJB remoting (which uses the SubordinationManager for importing a TX) and it is slow to prepare orphan detection may rollback one of its previously prepared XAResources. > We can detect if a subordinate TX is already running for a gtrid so we can use that. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Nov 14 02:13:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 14 Nov 2017 02:13:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2954: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2954 > URL: https://issues.jboss.org/browse/JBTM-2954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. > {code} > WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] > {code} > The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. > If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. > I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. > {code} > HTTP/1.1 200 OK > Connection: keep-alive > Content-Type: application/json > Content-Length: 359 > Date: Mon, 06 Nov 2017 09:14:44 GMT > {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} > {code} > Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Nov 16 03:46:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 16 Nov 2017 03:46:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka updated JBTM-2954: ---------------------------------- Steps to Reproduce: Start lra coordinator, use the curl to simulate {code} curl -i -X POST http://localhost:8080/lra-coordinator/start curl -i -X GET http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f curl -i -X GET -H "Accept: application/json" http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f curl -i -X GET -H "Accept: text/plain" http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f {code} was: Start lra coordinator, use the curl to simulate {code} curl -i -X POST http://localhost:8080/lra-coordinator/start curl -i -X GET http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f curl -i -X GET -H "Accept=application/json" http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f curl -i -X GET -H "Accept: text/plain" http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f {code} > LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2954 > URL: https://issues.jboss.org/browse/JBTM-2954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > > If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. > {code} > WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] > {code} > The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@Produces(MediaType.APPLICATION_JSON)}}. > If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. > I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. > {code} > HTTP/1.1 200 OK > Connection: keep-alive > Content-Type: application/json > Content-Length: 359 > Date: Mon, 06 Nov 2017 09:14:44 GMT > {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} > {code} > Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Nov 16 14:17:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 16 Nov 2017 14:17:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1732) Durable STM instances require explicit sync to save state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1258 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Durable STM instances require explicit sync to save state > --------------------------------------------------------- > > Key: JBTM-1732 > URL: https://issues.jboss.org/browse/JBTM-1732 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: STM > Affects Versions: 5.0.0.M3 > Reporter: Mark Little > Assignee: Mark Little > Priority: Optional > > As with TXOJ, a persistent STM object isn't written to disk until a write lock is acquired on it within the scope of a transaction. Consider automating this at creation time. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Nov 16 14:26:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Thu, 16 Nov 2017 14:26:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1732) Durable STM instances require explicit sync to save state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reassigned JBTM-1732: -------------------------------------- Assignee: Michael Musgrove (was: Mark Little) > Durable STM instances require explicit sync to save state > --------------------------------------------------------- > > Key: JBTM-1732 > URL: https://issues.jboss.org/browse/JBTM-1732 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: STM > Affects Versions: 5.0.0.M3 > Reporter: Mark Little > Assignee: Michael Musgrove > Priority: Optional > > As with TXOJ, a persistent STM object isn't written to disk until a write lock is acquired on it within the scope of a transaction. Consider automating this at creation time. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Nov 17 09:06:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 17 Nov 2017 09:06:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2960) STM quickstart commits an aborted action In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2960: -------------------------------------- Summary: STM quickstart commits an aborted action Key: JBTM-2960 URL: https://issues.jboss.org/browse/JBTM-2960 Project: JBoss Transaction Manager Issue Type: Bug Components: STM Affects Versions: 5.7.1.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next PCCExample STM quickstart commits an abort action and there is a typo in the attempt to compare the STM object with its clone. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Nov 17 09:08:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 17 Nov 2017 09:08:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2960) STM quickstart commits an aborted action In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #212 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > STM quickstart commits an aborted action > ---------------------------------------- > > Key: JBTM-2960 > URL: https://issues.jboss.org/browse/JBTM-2960 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: STM > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > PCCExample STM quickstart commits an abort action and there is a typo in the attempt to compare the STM object with its clone. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Mon Nov 20 05:21:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Mon, 20 Nov 2017 05:21:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2961) CDI checker has to start test swarm containers as process In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2961: ------------------------------------- Summary: CDI checker has to start test swarm containers as process Key: JBTM-2961 URL: https://issues.jboss.org/browse/JBTM-2961 Project: JBoss Transaction Manager Issue Type: Bug Components: REST Affects Versions: 5.7.1.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Attachments: console,.txt This is a follow-up to JBTM-2932. The cdi checker runs wfly swarm containers and checks if deployment exception is thrown when some compulsory annotations are not present in the deployment. But currently swarm is run as embedded but it's not a recommended approach (even it's deprecated) and swarm should be started as a new process. This makes troubles for ci machines in Newcastle. See logs. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Nov 21 08:11:00 2017 From: issues at jboss.org (Mark Little (JIRA)) Date: Tue, 21 Nov 2017 08:11:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2949) Remove synchronization from ThreadUtil.getThreadId In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492111#comment-13492111 ] Mark Little commented on JBTM-2949: ----------------------------------- Don't forget about public API changes, if any. > Remove synchronization from ThreadUtil.getThreadId > -------------------------------------------------- > > Key: JBTM-2949 > URL: https://issues.jboss.org/browse/JBTM-2949 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Reporter: Luis Barreiro > Attachments: specj_349Q.png > > > JBTM-2808 adds synchronization on {{ThreadUtil.getThreadId()}} but that solution does not scale well enough under high contention. > There seems to be ways to remove this synchronization: > # *ConcurrentWeakHashMap* - replace the current {{WeakHashMap}} for a similar data structure that can handle concurrent access. This keeps the same behavior. > # *Use Thread.getId()* - remove all mappings and generate the {{threadId}} from the {{Thread}}. Although the javadoc mentions that IDs can be reused, the implementation is a counter, like what {{ThreadUtil}} has now. This is the simplest and most elegant fix. > # *Remove {{threadId}}* - remove the generation of {{threadId}} and use the {{Thread}} throughout the code, generating string IDs when necessary. Probably yields the best performance, but requires the most changes. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Nov 21 08:32:00 2017 From: issues at jboss.org (Mark Little (JIRA)) Date: Tue, 21 Nov 2017 08:32:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2962) Quickstart README indicates all quoickstarts need an app server In-Reply-To: References: Message-ID: Mark Little created JBTM-2962: --------------------------------- Summary: Quickstart README indicates all quoickstarts need an app server Key: JBTM-2962 URL: https://issues.jboss.org/browse/JBTM-2962 Project: JBoss Transaction Manager Issue Type: Bug Components: Demonstrator Reporter: Mark Little Priority: Minor The Narayana Quickstart top-level README tells people to set JBOSS_HOME to run quickstarts but not all of them need an app server, let alone a Java EE app server. I'm thinking specifically about Vert.x and perhaps any Swarm examples. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Nov 21 08:33:00 2017 From: issues at jboss.org (Mark Little (JIRA)) Date: Tue, 21 Nov 2017 08:33:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2962) Quickstart README indicates all quoickstarts need an app server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Little reassigned JBTM-2962: --------------------------------- Assignee: Michael Musgrove > Quickstart README indicates all quoickstarts need an app server > --------------------------------------------------------------- > > Key: JBTM-2962 > URL: https://issues.jboss.org/browse/JBTM-2962 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Reporter: Mark Little > Assignee: Michael Musgrove > Priority: Minor > > The Narayana Quickstart top-level README tells people to set JBOSS_HOME to run quickstarts but not all of them need an app server, let alone a Java EE app server. I'm thinking specifically about Vert.x and perhaps any Swarm examples. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Nov 21 09:32:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 21 Nov 2017 09:32:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2963) Upgrade Artemis Journal to match version in WildFly In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2963: ----------------------------------- Summary: Upgrade Artemis Journal to match version in WildFly Key: JBTM-2963 URL: https://issues.jboss.org/browse/JBTM-2963 Project: JBoss Transaction Manager Issue Type: Component Upgrade Components: Transaction Core Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next Sync up with the version in WFLY-9345 rather than latest 2 release. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Nov 21 09:33:01 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 21 Nov 2017 09:33:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2963) Upgrade Artemis Journal to match version in WildFly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Tom Jenkinson created pull request #1259 in GitHub -------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Upgrade Artemis Journal to match version in WildFly > --------------------------------------------------- > > Key: JBTM-2963 > URL: https://issues.jboss.org/browse/JBTM-2963 > Project: JBoss Transaction Manager > Issue Type: Component Upgrade > Components: Transaction Core > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Sync up with the version in WFLY-9345 rather than latest 2 release. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Nov 21 09:37:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 21 Nov 2017 09:37:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2960) STM quickstart commits an aborted action In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-2960: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > STM quickstart commits an aborted action > ---------------------------------------- > > Key: JBTM-2960 > URL: https://issues.jboss.org/browse/JBTM-2960 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: STM > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > PCCExample STM quickstart commits an abort action and there is a typo in the attempt to compare the STM object with its clone. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Nov 21 09:42:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 21 Nov 2017 09:42:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-1732) Durable STM instances require explicit sync to save state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-1732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove updated JBTM-1732: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Durable STM instances require explicit sync to save state > --------------------------------------------------------- > > Key: JBTM-1732 > URL: https://issues.jboss.org/browse/JBTM-1732 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: STM > Affects Versions: 5.0.0.M3 > Reporter: Mark Little > Assignee: Michael Musgrove > Priority: Optional > > As with TXOJ, a persistent STM object isn't written to disk until a write lock is acquired on it within the scope of a transaction. Consider automating this at creation time. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Nov 21 10:40:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Tue, 21 Nov 2017 10:40:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2964) Clarify the build instructions in the README In-Reply-To: References: Message-ID: Tom Jenkinson created JBTM-2964: ----------------------------------- Summary: Clarify the build instructions in the README Key: JBTM-2964 URL: https://issues.jboss.org/browse/JBTM-2964 Project: JBoss Transaction Manager Issue Type: Task Reporter: Tom Jenkinson Assignee: Tom Jenkinson Fix For: 5.next There are parts of the readme that are unclear about how to build individual modules or skipping tests. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Nov 21 11:06:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 21 Nov 2017 11:06:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2965) Unused source directory in the quickstart repository In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2965: -------------------------------------- Summary: Unused source directory in the quickstart repository Key: JBTM-2965 URL: https://issues.jboss.org/browse/JBTM-2965 Project: JBoss Transaction Manager Issue Type: Task Components: Demonstrator Affects Versions: 5.7.1.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Priority: Minor Fix For: 5.next There is an artifact in our quickstart repo that does not look like a quickstart and no other pom in the quickstart and performance repositories references the artifact: https://github.com/jbosstm/quickstart/tree/master/ArjunaJTS/jta It has never changed since the initial commit: {quote} commit caabc37803bac12e47f4986baca21f9052e14abc Author: Tom Jenkinson Date: Tue Oct 2 11:05:51 2012 +0100 Initial version of a performance comparitor for jts and jta {quote} This artefact needs deleting. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Nov 21 12:26:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 21 Nov 2017 12:26:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2966) narayana-quickstarts-jts quickstart does not run standalone In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2966: -------------------------------------- Summary: narayana-quickstarts-jts quickstart does not run standalone Key: JBTM-2966 URL: https://issues.jboss.org/browse/JBTM-2966 Project: JBoss Transaction Manager Issue Type: Bug Components: Demonstrator Affects Versions: 5.7.1.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The recovery quickstart does not run due to missing maven jboss-transaction-spi dependency. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Nov 21 12:37:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 21 Nov 2017 12:37:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2967) Some quickstarts are not tested in CI In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2967: -------------------------------------- Summary: 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 Tue Nov 21 12:58:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 21 Nov 2017 12:58:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2968) Some JTS quickstarts run with JacORB In-Reply-To: References: Message-ID: Michael Musgrove created JBTM-2968: -------------------------------------- Summary: 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 Tue Nov 21 13:46:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 21 Nov 2017 13:46:00 -0500 (EST) 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 ] Issue was automatically transitioned when Michael Musgrove created pull request #213 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > narayana-quickstarts-jts quickstart does not run standalone > ----------------------------------------------------------- > > Key: JBTM-2966 > URL: https://issues.jboss.org/browse/JBTM-2966 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The recovery quickstart does not run due to missing maven jboss-transaction-spi dependency. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Nov 21 13:49:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 21 Nov 2017 13:49:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2962) Quickstart README indicates all quoickstarts need an app server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #215 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Quickstart README indicates all quoickstarts need an app server > --------------------------------------------------------------- > > Key: JBTM-2962 > URL: https://issues.jboss.org/browse/JBTM-2962 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Demonstrator > Reporter: Mark Little > Assignee: Michael Musgrove > Priority: Minor > > The Narayana Quickstart top-level README tells people to set JBOSS_HOME to run quickstarts but not all of them need an app server, let alone a Java EE app server. I'm thinking specifically about Vert.x and perhaps any Swarm examples. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Nov 21 13:49:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Tue, 21 Nov 2017 13:49:00 -0500 (EST) 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 ] Issue was automatically transitioned when Michael Musgrove created pull request #214 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Unused source directory in the quickstart repository > ---------------------------------------------------- > > Key: JBTM-2965 > URL: https://issues.jboss.org/browse/JBTM-2965 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator > Affects Versions: 5.7.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > There is an artifact in our quickstart repo that does not look like a quickstart and no other pom in the quickstart and performance repositories references the artifact: > https://github.com/jbosstm/quickstart/tree/master/ArjunaJTS/jta > It has never changed since the initial commit: > {quote} > commit caabc37803bac12e47f4986baca21f9052e14abc > Author: Tom Jenkinson > Date: Tue Oct 2 11:05:51 2012 +0100 > Initial version of a performance comparitor for jts and jta > {quote} > This artefact needs deleting. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Nov 22 06:23:01 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 22 Nov 2017 06:23:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reopened JBTM-2206: ------------------------------------ > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Tom Jenkinson > Priority: Minor > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Nov 22 06:25:01 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 22 Nov 2017 06:25:01 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492732#comment-13492732 ] Michael Musgrove commented on JBTM-2206: ---------------------------------------- Reopened since there was an issue with the original performance test and after fixing that we are seeing a significant speed improvement on two of the tests (see linked PR for details). > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Tom Jenkinson > Priority: Minor > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Nov 22 06:31:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 22 Nov 2017 06:31:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2206) Use synchronized HashMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reassigned JBTM-2206: -------------------------------------- Assignee: Michael Musgrove (was: Tom Jenkinson) > Use synchronized HashMaps > ------------------------- > > Key: JBTM-2206 > URL: https://issues.jboss.org/browse/JBTM-2206 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Transaction Core > Reporter: Jesper Pedersen > Assignee: Michael Musgrove > Priority: Minor > > Change usage of Hashtable into synchronized HashMap's instead. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Nov 22 11:36:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 22 Nov 2017 11:36:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2961) CDI checker has to start test swarm containers as process In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #1260 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > CDI checker has to start test swarm containers as process > --------------------------------------------------------- > > Key: JBTM-2961 > URL: https://issues.jboss.org/browse/JBTM-2961 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Attachments: console,.txt > > > This is a follow-up to JBTM-2932. > The cdi checker runs wfly swarm containers and checks if deployment exception is thrown when some compulsory annotations are not present in the deployment. > But currently swarm is run as embedded but it's not a recommended approach (even it's deprecated) and swarm should be started as a new process. This makes troubles for ci machines in Newcastle. See logs. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Nov 22 11:58:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 22 Nov 2017 11:58:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2961) CDI checker has to start test swarm containers as process In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13493048#comment-13493048 ] Michael Musgrove commented on JBTM-2961: ---------------------------------------- I pushed a commit tha temporarily disabling the lra cdi checker whilst we investigate why it fails on mac builds. > CDI checker has to start test swarm containers as process > --------------------------------------------------------- > > Key: JBTM-2961 > URL: https://issues.jboss.org/browse/JBTM-2961 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Attachments: console,.txt > > > This is a follow-up to JBTM-2932. > The cdi checker runs wfly swarm containers and checks if deployment exception is thrown when some compulsory annotations are not present in the deployment. > But currently swarm is run as embedded but it's not a recommended approach (even it's deprecated) and swarm should be started as a new process. This makes troubles for ci machines in Newcastle. See logs. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Nov 22 11:59:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Wed, 22 Nov 2017 11:59:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2961) CDI checker has to start test swarm containers as process In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13493048#comment-13493048 ] Michael Musgrove edited comment on JBTM-2961 at 11/22/17 11:58 AM: ------------------------------------------------------------------- I pushed a commit that temporarily disables the lra cdi checker whilst we investigate why it is failing on mac builds. was (Author: mmusgrov): I pushed a commit tha temporarily disabling the lra cdi checker whilst we investigate why it fails on mac builds. > CDI checker has to start test swarm containers as process > --------------------------------------------------------- > > Key: JBTM-2961 > URL: https://issues.jboss.org/browse/JBTM-2961 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Attachments: console,.txt > > > This is a follow-up to JBTM-2932. > The cdi checker runs wfly swarm containers and checks if deployment exception is thrown when some compulsory annotations are not present in the deployment. > But currently swarm is run as embedded but it's not a recommended approach (even it's deprecated) and swarm should be started as a new process. This makes troubles for ci machines in Newcastle. See logs. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Nov 24 07:39:00 2017 From: issues at jboss.org (Tom Jenkinson (JIRA)) Date: Fri, 24 Nov 2017 07:39:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2948) NullPointer exception when beforeCompletion callback fails to prepare In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tom Jenkinson updated JBTM-2948: -------------------------------- Fix Version/s: 5.next (was: 5.7.2.Final) > NullPointer exception when beforeCompletion callback fails to prepare > --------------------------------------------------------------------- > > Key: JBTM-2948 > URL: https://issues.jboss.org/browse/JBTM-2948 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Transaction Core, XTS > Affects Versions: 5.7.0.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.next > > > In case of before completion fails to be processed it happens to be called a handler of {{preventCompletion}}. There is potential issue of receiving {{NullPointerException}} as rollback is called and there was not created lists (heuristic one in particular) as {{prepare}} was not processed. > This situation could happen in case of trouble of WS-AT XTS of volatile participant. > Let's look at the stack trace talk. > First this is a failure of the beforeCompletion > {code} > TRACE [com.arjuna.ats.jta] (executor-2) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE > WARN [com.arjuna.ws.wscf] (executor-1) ARJUNA044067: SynchronizationRecord.beforeCompletion caught exception: com.arjuna.mw.wsas.exceptions.SystemException: com.arjuna.wst.stub.SystemCommunicationException > at com.arjuna.mwlabs.wst.at.participants.VolatileTwoPhaseCommitParticipant.beforeCompletion(VolatileTwoPhaseCommitParticipant.java:98) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.SynchronizationRecord.beforeCompletion(SynchronizationRecord.java:77) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.prepareVolatile(SubordinateATCoordinator.java:147) > at org.jboss.jbossts.xts.bridge.at.BridgeWrapper.prepareVolatile(BridgeWrapper.java:200) > at org.jboss.jbossts.txbridge.outbound.BridgeSynchronization.beforeCompletion(BridgeSynchronization.java:57) > at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:371) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) > at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:193) > TRACE [com.arjuna.ats.arjuna] (executor-1) BasicAction::preventCommit( BasicAction: 0:ffffa70a35d8:6cd5ba87:59e51f1b:1d status: ActionStatus.RUNNING) > WARN [com.arjuna.ats.arjuna] (executor-1) ARJUNA012125: TwoPhaseCoordinator.beforeCompletion - failed for SynchronizationImple< 0:ffffa70a35d8:6cd5ba87:59e51f1b:22, org.jboss.jbossts.txbridge.outbound.BridgeSynchronization at 5b29778 >: java.lang.RuntimeException: BridgeWrapper.prepareVolatile() returned false > {code} > as that failure happens we can see the later {{NullPointer}} > {code} > WARN [com.arjuna.ats.arjuna] (executor-1) ARJUNA012089: Top-level abort of action 0:ffffa70a35d8:6cd5ba87:59e51f1b:1d received heuristic decision: TwoPhaseOutcome.HEURISTIC_HAZARD > WARN [com.arjuna.ats.jta] (executor-1) ARJUNA016045: attempted rollback of < formatId=131077, gtrid_length=37, bqual_length=36, tx_uid=0:ffffa70a35d8:6cd5ba87:59e51f1b:1c, node_name=csarTst03, branch_uid=0:ffffa70a35d8:6cd5ba87:59e51f1b:1f, subordinatenodename=null, eis_name=unknown eis name > (org.jboss.jbossts.txbridge.outbound.BridgeXAResource at 3d67708e) failed with exception code -: java.lang.NullPointerException > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3031) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2979) > at com.arjuna.ats.arjuna.coordinator.BasicAction.phase2Abort(BasicAction.java:1961) > at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.subordinate.SubordinateATCoordinator.rollback(SubordinateATCoordinator.java:240) > at org.jboss.jbossts.xts.bridge.at.BridgeWrapper.rollback(BridgeWrapper.java:246) > at org.jboss.jbossts.txbridge.outbound.BridgeXAResource.rollback(BridgeXAResource.java:251) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:369) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3000) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:2979) > at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1658) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:99) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) > at org.jboss.tm.usertx.client.ServerVMClientUserTransaction.commit(ServerVMClientUserTransaction.java:193) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Nov 24 07:39:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 24 Nov 2017 07:39:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2889) Include a vertx with STM quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Musgrove reopened JBTM-2889: ------------------------------------ I am reopening since I want to replace the quickstart with a link to a [better one|https://github.com/jbosstm/conferences/tree/master/mucon2017] in our conferences repositiory: > Include a vertx with STM quickstart > ----------------------------------- > > Key: JBTM-2889 > URL: https://issues.jboss.org/browse/JBTM-2889 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator, STM > Affects Versions: 4.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.6.0.Final > > > It would be useful to include a quickstart that shows how to use STM with vertx -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Fri Nov 24 07:44:00 2017 From: issues at jboss.org (Michael Musgrove (JIRA)) Date: Fri, 24 Nov 2017 07:44:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2889) Include a vertx with STM quickstart In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Issue was automatically transitioned when Michael Musgrove created pull request #216 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Reopened) > Include a vertx with STM quickstart > ----------------------------------- > > Key: JBTM-2889 > URL: https://issues.jboss.org/browse/JBTM-2889 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Demonstrator, STM > Affects Versions: 4.2 > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.6.0.Final > > > It would be useful to include a quickstart that shows how to use STM with vertx -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Nov 28 08:12:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 28 Nov 2017 08:12:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2961) CDI checker has to start test swarm containers as process In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka closed JBTM-2961. --------------------------------- Resolution: Done After talk with Mike I need to use another approach with the checker. Closing this one, currently leaving the cdi checker ignored from the lra build. > CDI checker has to start test swarm containers as process > --------------------------------------------------------- > > Key: JBTM-2961 > URL: https://issues.jboss.org/browse/JBTM-2961 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Attachments: console,.txt > > > This is a follow-up to JBTM-2932. > The cdi checker runs wfly swarm containers and checks if deployment exception is thrown when some compulsory annotations are not present in the deployment. > But currently swarm is run as embedded but it's not a recommended approach (even it's deprecated) and swarm should be started as a new process. This makes troubles for ci machines in Newcastle. See logs. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Tue Nov 28 08:15:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Tue, 28 Nov 2017 08:15:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2969) Make the CDI checker a standalone tool or/and mvn plugin In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2969: ------------------------------------- Summary: Make the CDI checker a standalone tool or/and mvn plugin Key: JBTM-2969 URL: https://issues.jboss.org/browse/JBTM-2969 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.7.1.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka The way how the checker works now (as CDI extension, needed to be packed inside of the app) is not a good approach and it should work as a standalone tool or better as a maven plugin to verify the annotation in a defined phase. The current approach needs to be reworked. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Wed Nov 29 04:48:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Wed, 29 Nov 2017 04:48:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2942) LRA tests failed when building with the JDK9 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495069#comment-13495069 ] Ondra Chaloupka commented on JBTM-2942: --------------------------------------- The Swarm issue on supporting JDK9 is here: https://issues.jboss.org/browse/SWARM-1594 > LRA tests failed when building with the JDK9 > -------------------------------------------- > > Key: JBTM-2942 > URL: https://issues.jboss.org/browse/JBTM-2942 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.0.Final > Reporter: Amos Feng > Assignee: Amos Feng > Labels: jdk9 > > The lra-test still failed with java.lang.IllegalArgumentException when deploying the war. It looks like the wildfly-swarm does support the JDK9 currently. Also I find 1 and 2 with the same issues. > 1. https://stackoverflow.com/questions/46449735/wildfly-swarm-deployment-crash-with-java-9 > 2. https://stackoverflow.com/questions/42990017/illegalargumentexception-while-starting-wildfly-swarm-provided-custom-main-meth -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Nov 30 05:20:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 30 Nov 2017 05:20:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2221) Remove old TXFramework API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ondra Chaloupka reassigned JBTM-2221: ------------------------------------- Assignee: Ondra Chaloupka (was: Paul Robinson) > Remove old TXFramework API > -------------------------- > > Key: JBTM-2221 > URL: https://issues.jboss.org/browse/JBTM-2221 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Tom Jenkinson > Assignee: Ondra Chaloupka > Fix For: 6.later > > > This is now replaced by the CDI based Compensations API. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Nov 30 05:21:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 30 Nov 2017 05:21:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2221) Remove old TXFramework API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/JBTM-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13495640#comment-13495640 ] Ondra Chaloupka commented on JBTM-2221: --------------------------------------- We've mentioned this at the meeting and this should be considered for version 6.0.0 when it comes. > Remove old TXFramework API > -------------------------- > > Key: JBTM-2221 > URL: https://issues.jboss.org/browse/JBTM-2221 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Compensations > Reporter: Tom Jenkinson > Assignee: Ondra Chaloupka > Fix For: 6.later > > > This is now replaced by the CDI based Compensations API. -- This message was sent by Atlassian JIRA (v7.5.0#75005) From issues at jboss.org Thu Nov 30 05:28:00 2017 From: issues at jboss.org (Ondra Chaloupka (JIRA)) Date: Thu, 30 Nov 2017 05:28:00 -0500 (EST) Subject: [jbossts-issues] [JBoss JIRA] (JBTM-2970) Investigate on transaction SPI usage and if necessary for WFLY integration In-Reply-To: References: Message-ID: Ondra Chaloupka created JBTM-2970: ------------------------------------- Summary: Investigate on transaction SPI usage and if necessary for WFLY integration Key: JBTM-2970 URL: https://issues.jboss.org/browse/JBTM-2970 Project: JBoss Transaction Manager Issue Type: Task Components: Application Server Integration, SPI Affects Versions: 5.7.1.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka Attachments: eap6-txn-dependencies.jpg, eap71-txn-dependencies.jpg The transaction integration code in WFLY is pretty complicated. With the introduction of WildFly transaction client come one more layer of abstraction and especially it should be rethought what is the reason for using SPI there. More than half a classes in SPI are deprecated. It would be good to understand if they are necessary or if some refactoring would be beneficial. As an ilustration attaching a graphic of transaction dependencies in WildFly 11. -- This message was sent by Atlassian JIRA (v7.5.0#75005)