[JBoss JIRA] (JBTM-2955) Add a filter that checks for running subordinate transactions before identifying a branch as orphaned
by Tom Jenkinson (JIRA)
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)
6 years, 6 months
[JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.... ]
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 - {{(a)Produces(MediaType.TEXT_PLAIN)}} vs {{(a)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-coordina...) (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 - {{(a)Produces(MediaType.TEXT_PLAIN)}} vs {{(a)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-coordina...) (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 - {{(a)Produces(MediaType.TEXT_PLAIN)}} vs {{(a)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-coordina...) (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)
6 years, 6 months
[JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.... ]
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 - {{(a)Produces(MediaType.TEXT_PLAIN)}} vs {{(a)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-coordina...) (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)
6 years, 6 months
[JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204
by Ondra Chaloupka (JIRA)
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 - {{(a)Produces(MediaType.TEXT_PLAIN)}} vs {{(a)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-coordina...) (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)
6 years, 6 months
[JBoss JIRA] (JBTM-2949) Remove synchronization from ThreadUtil.getThreadId
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-2949?page=com.atlassian.jira.plugin.... ]
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)
6 years, 6 months
[JBoss JIRA] (JBTM-2124) Add orphan detection for JTS interposition mode
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2124?page=com.atlassian.jira.plugin.... ]
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)
6 years, 6 months
[JBoss JIRA] (JBTM-2952) LRA rest cdi checker should not demand @Status
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2952?page=com.atlassian.jira.plugin.... ]
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)
6 years, 6 months
[JBoss JIRA] (JBTM-2950) LRA logging is wrong in pointing to tsLogger and using System.out
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2950?page=com.atlassian.jira.plugin.... ]
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)
6 years, 6 months
[JBoss JIRA] (JBTM-2951) Application using LRAClient starts with multiple warnings
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2951?page=com.atlassian.jira.plugin.... ]
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)
6 years, 6 months