November 2017 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.... ] 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 - {{(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, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.... ] 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 - {{(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, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.... ] 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 - {{(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, 5 months

1
0
0 / 0

[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: --------------------------------------- hi [~mmusgrov], my idea of the fix is here: https://github.com/ochaloup/narayana/commit/30d4f36ba9d2216ed25fb7bc7fe30... 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%3A8... Location: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8... curl -i -X PUT http://localhost:8080/lra-coordinator/0_ffff0a000007_-4bbc6a89_5a097341_f... 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 - {{(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, 5 months

1
0
0 / 0

[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: ---------------------------------- 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 - {{(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, 5 months

1
0
0 / 0

[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: --------------------------------------- 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 - {{(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, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.... ] 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 - {{(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, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2949) Remove synchronization from ThreadUtil.getThreadId

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2949?page=com.atlassian.jira.plugin.... ] 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)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2956) Add a simple pooling datasource wrapper

by Tom Jenkinson (JIRA)

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)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2949) Remove synchronization from ThreadUtil.getThreadId

by Luis Barreiro (JIRA)

[ https://issues.jboss.org/browse/JBTM-2949?page=com.atlassian.jira.plugin.... ] 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)

6 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues November 2017