January 2018 - jbossts-issues - Jboss List Archives

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

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2956?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2956. ------------------------------- Resolution: Done > 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.7.2.Final > > > 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, 10 months

1
0
0 / 0

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

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1732?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-1732: -------------------------------- Fix Version/s: 5.7.2.Final > 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 > Fix For: 5.7.2.Final > > > 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, 10 months

1
0
0 / 0

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

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-1732?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-1732. ------------------------------- > 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 > Fix For: 5.7.2.Final > > > 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, 10 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 Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2954: -------------------------------- Fix Version/s: 5.7.2.Final > 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 > Fix For: 5.7.2.Final > > > 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, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2964) Clarify the build instructions in the README

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2964?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2964. ------------------------------- Resolution: Done > 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)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2963) Upgrade Artemis Journal to match version in WildFly

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2963?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2963. ------------------------------- Resolution: Done > 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)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2972) Add connection pooling facilities to transactionaldriver such that it will allow close to return the connection to the pool

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2972?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2972. ------------------------------- Assignee: Tom Jenkinson > Add connection pooling facilities to transactionaldriver such that it will allow close to return the connection to the pool > --------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2972 > URL: https://issues.jboss.org/browse/JBTM-2972 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.next > > > Currently the connection is pooled in that that the same connection is returned during a TX. We would like to return the connection to the pool so that it can be reused. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2973) Direct recoverable connection is not serialized in object store to be "directly" recoverable

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2973?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2973: -------------------------------- Fix Version/s: 5.7.2.Final > Direct recoverable connection is not serialized in object store to be "directly" recoverable > -------------------------------------------------------------------------------------------- > > Key: JBTM-2973 > URL: https://issues.jboss.org/browse/JBTM-2973 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.7.2.Final > > > On working with {{com.arjuna.ats.internal.jdbc.DirectRecoverableConnection}} I found out that state is not saved correctly for the connection could be restored from the object store and recovered. > The issue happens to be in case the direct recoverable {{XAResource}} throws {{XAException.XAER_RMFAIL}} on commit. That means the resource is not ready to commit but recovery should retry. In case of the {{DirectRecoverableConnection}} the state should be serialized and then restored from object store and used for recovery. > {{XAResourceRecord#prepare}} causes the connection ({{_recoveryObject}}) is saved under object store but then if fails on commit happens the {{XAResourceRecord#removeConnection}} is called where {{_recoveryObject}} is set to null and now the {{BasicAction#phase2Commit}} on call of {{updateState}} (call {{if (!save_state(state, ObjectType.ANDPERSISTENT))}}) tries to update state but the recovery object is already null and the old {{prepare}} version is overriden by {{commit}} one which has already removed information that the object is directly recoverable. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2973) Direct recoverable connection is not serialized in object store to be "directly" recoverable

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2973?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2973. ------------------------------- > Direct recoverable connection is not serialized in object store to be "directly" recoverable > -------------------------------------------------------------------------------------------- > > Key: JBTM-2973 > URL: https://issues.jboss.org/browse/JBTM-2973 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.7.2.Final > > > On working with {{com.arjuna.ats.internal.jdbc.DirectRecoverableConnection}} I found out that state is not saved correctly for the connection could be restored from the object store and recovered. > The issue happens to be in case the direct recoverable {{XAResource}} throws {{XAException.XAER_RMFAIL}} on commit. That means the resource is not ready to commit but recovery should retry. In case of the {{DirectRecoverableConnection}} the state should be serialized and then restored from object store and used for recovery. > {{XAResourceRecord#prepare}} causes the connection ({{_recoveryObject}}) is saved under object store but then if fails on commit happens the {{XAResourceRecord#removeConnection}} is called where {{_recoveryObject}} is set to null and now the {{BasicAction#phase2Commit}} on call of {{updateState}} (call {{if (!save_state(state, ObjectType.ANDPERSISTENT))}}) tries to update state but the recovery object is already null and the old {{prepare}} version is overriden by {{commit}} one which has already removed information that the object is directly recoverable. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2972) Add connection pooling facilities to transactionaldriver such that it will allow close to return the connection to the pool

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2972?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2972: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Add connection pooling facilities to transactionaldriver such that it will allow close to return the connection to the pool > --------------------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2972 > URL: https://issues.jboss.org/browse/JBTM-2972 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Tom Jenkinson > Fix For: 5.next > > > Currently the connection is pooled in that that the same connection is returned during a TX. We would like to return the connection to the pool so that it can be reused. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 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 January 2018