November 2017 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2961) CDI checker has to start test swarm containers as process

by Ondra Chaloupka (JIRA)

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)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2960) STM quickstart commits an aborted action

by Michael Musgrove (JIRA)

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

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2960) STM quickstart commits an aborted action

by Michael Musgrove (JIRA)

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)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1732) Durable STM instances require explicit sync to save state

by Michael Musgrove (JIRA)

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

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-1732) Durable STM instances require explicit sync to save state

by Michael Musgrove (JIRA)

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

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/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 - {{(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: ---------------------------------- 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 - {{(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-2955) Add a filter that checks for running subordinate transactions before identifying a branch as orphaned

by Tom Jenkinson (JIRA)

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

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2959) Allow different LRA coordinators to share an object store

by Michael Musgrove (JIRA)

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

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2957) LRA specification: descriptions for start/end and LRA do not say which response codes are valid

by Michael Musgrove (JIRA)

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

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