December 2017 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2981) Transactional annotation on per method basis?

by Mark Little (JIRA)

Mark Little created JBTM-2981: --------------------------------- Summary: Transactional annotation on per method basis? Key: JBTM-2981 URL: https://issues.jboss.org/browse/JBTM-2981 Project: JBoss Transaction Manager Issue Type: Feature Request Components: STM Reporter: Mark Little Assignee: Mark Little Similar to TransactionFree, do we need a method-level annotation that says "create transaction" regardless? We have class-specific annotations. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2980) recreate method instead of (as well as?) clone on container?

by Mark Little (JIRA)

Mark Little created JBTM-2980: --------------------------------- Summary: recreate method instead of (as well as?) clone on container? Key: JBTM-2980 URL: https://issues.jboss.org/browse/JBTM-2980 Project: JBoss Transaction Manager Issue Type: Feature Request Components: STM Reporter: Mark Little Assignee: Mark Little Just wondering if the clone method (for recreating persistent objects) is poorly named or we need a recreate as well? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2979) Timeout leaves LRA active and able to complete

by Nicola Ferraro (JIRA)

Nicola Ferraro created JBTM-2979: ------------------------------------ Summary: Timeout leaves LRA active and able to complete Key: JBTM-2979 URL: https://issues.jboss.org/browse/JBTM-2979 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.7.1.Final Reporter: Nicola Ferraro Assignee: Michael Musgrove If a participant declares a timeout, the coordinator calls its "/compensate" endpoint when the timeout expires. But the LRA remains active and it may be possibly closed, leading to a second call to "/complete" on the participant, even if he has already compensated. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2978) Compensation should not be considered done in case of network error

by Nicola Ferraro (JIRA)

Nicola Ferraro created JBTM-2978: ------------------------------------ Summary: Compensation should not be considered done in case of network error Key: JBTM-2978 URL: https://issues.jboss.org/browse/JBTM-2978 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.7.1.Final Reporter: Nicola Ferraro Assignee: Michael Musgrove In case of network error on the call to "/compensate" made by the coordinator to the participant, the LRA is considered compensated, hence the compensate action is not retried again. This is not the expected behavior. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2977) Participants should not be told to compensate after completion

by Nicola Ferraro (JIRA)

[ https://issues.jboss.org/browse/JBTM-2977?page=com.atlassian.jira.plugin.... ] Nicola Ferraro updated JBTM-2977: --------------------------------- Steps to Reproduce: {code} # # Shell 1: listen for connections (does not reply) and print output nc -kl 8888 # Shell 2: create a saga and close it COORDINATOR_URL=http://localhost:8080/lra-coordinator echo "Creating new LRA" LRA_URL=$(curl -X POST $COORDINATOR_URL/start | sed "s/\"//g") echo "Joining LRA" curl -X PUT $LRA_URL -d http://localhost:8888 echo "Close LRA" curl -X PUT $LRA_URL/close # Output of shell 1 PUT /complete HTTP/1.1 Accept-Encoding: gzip, deflate Content-Type: application/json Long-Running-Action: http://localhost:8080/lra-coordinator/0_ffff0a2140b4_-14db9cf6_5a3bdf77_241 Long-Running-Action-Recovery: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8... Content-Length: 0 Host: localhost:8888 Connection: Keep-Alive ###### After some seconds, when periodic recovery starts ###### PUT /compensate HTTP/1.1 Accept-Encoding: gzip, deflate Content-Type: application/json Long-Running-Action: http://localhost:8080/lra-coordinator/0_ffff0a2140b4_-14db9cf6_5a3bdf77_241 Long-Running-Action-Recovery: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8... Content-Length: 0 Host: localhost:8888 Connection: Keep-Alive {code} was: {code} # # Shell 1: listen for connections (does not reply) and print output nc -kl 8888 # Shell 2: create a saga and close it COORDINATOR_URL=http://localhost:8080/lra-coordinator echo "Creating new LRA" LRA_URL=$(curl -X POST $COORDINATOR_URL/start | sed "s/\"//g") echo "Joining LRA" curl -X PUT $LRA_URL -d http://localhost:8888 echo "Close LRA" curl -X PUT $LRA_URL/close # Output of shell 1 PUT /compensate HTTP/1.1 Accept-Encoding: gzip, deflate Content-Type: application/json Long-Running-Action: http://localhost:8080/lra-coordinator/0_ffff0a2140b4_-14db9cf6_5a3bdf77_241 Long-Running-Action-Recovery: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8... Content-Length: 0 Host: localhost:8888 Connection: Keep-Alive ###### After some seconds, when periodic recovery starts ###### PUT /compensate HTTP/1.1 Accept-Encoding: gzip, deflate Content-Type: application/json Long-Running-Action: http://localhost:8080/lra-coordinator/0_ffff0a2140b4_-14db9cf6_5a3bdf77_241 Long-Running-Action-Recovery: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8... Content-Length: 0 Host: localhost:8888 Connection: Keep-Alive {code} > Participants should not be told to compensate after completion > -------------------------------------------------------------- > > Key: JBTM-2977 > URL: https://issues.jboss.org/browse/JBTM-2977 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Nicola Ferraro > Assignee: Michael Musgrove > > When a LRA is closed the coordinator behaves incorrectly if a participant is slow to respond. > While the call to "/complete" is still ongoing, the coordinator (recovery module) may issue a second call to "/compensate", making it impossible for the participant to determine when a LRA is really closed. > The LRA coordinator must choose a single outcome for the LRA and be consistent with that (retrying until all participants are in status complete/failedtocomplete in this case). > A second minor problem is that the call to "/close" is synchronous, and the caller is kept attached forever if the participant does not respond to "/complete". It would be better to establish a timeout and return a "Completing" status if not all participant are done in time. > I attach few simple steps to reproduce it with shell commands. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2977) Participants should not be told to compensate after completion

by Nicola Ferraro (JIRA)

[ https://issues.jboss.org/browse/JBTM-2977?page=com.atlassian.jira.plugin.... ] Nicola Ferraro updated JBTM-2977: --------------------------------- Steps to Reproduce: {code} # # Shell 1: listen for connections (does not reply) and print output nc -kl 8888 # Shell 2: create a saga and close it COORDINATOR_URL=http://localhost:8080/lra-coordinator echo "Creating new LRA" LRA_URL=$(curl -X POST $COORDINATOR_URL/start | sed "s/\"//g") echo "Joining LRA" curl -X PUT $LRA_URL -d http://localhost:8888 echo "Close LRA" curl -X PUT $LRA_URL/close # Output of shell 1 PUT /compensate HTTP/1.1 Accept-Encoding: gzip, deflate Content-Type: application/json Long-Running-Action: http://localhost:8080/lra-coordinator/0_ffff0a2140b4_-14db9cf6_5a3bdf77_241 Long-Running-Action-Recovery: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8... Content-Length: 0 Host: localhost:8888 Connection: Keep-Alive ###### After some seconds, when periodic recovery starts ###### PUT /compensate HTTP/1.1 Accept-Encoding: gzip, deflate Content-Type: application/json Long-Running-Action: http://localhost:8080/lra-coordinator/0_ffff0a2140b4_-14db9cf6_5a3bdf77_241 Long-Running-Action-Recovery: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8... Content-Length: 0 Host: localhost:8888 Connection: Keep-Alive {code} was: {code} # # Shell 1: listen for connections (does not reply) and print output nc -kl 8888 # Shell 2: create a saga and close it COORDINATOR_URL=http://localhost:8080/lra-coordinator echo "Creating new LRA" LRA_URL=$(curl -X POST $COORDINATOR_URL/start | sed "s/\"//g") echo "Joining LRA" curl -X PUT $LRA_URL -d http://localhost:8888 echo "Close LRA" curl -X PUT $LRA_URL/close # Output of shell 1 Accept-Encoding: gzip, deflate Content-Type: application/json Long-Running-Action: http://localhost:8080/lra-coordinator/0_ffff0a2140b4_-14db9cf6_5a3bdf77_241 Long-Running-Action-Recovery: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8... Content-Length: 0 Host: localhost:8888 Connection: Keep-Alive ###### After some seconds, when periodic recovery starts ###### PUT /compensate HTTP/1.1 Accept-Encoding: gzip, deflate Content-Type: application/json Long-Running-Action: http://localhost:8080/lra-coordinator/0_ffff0a2140b4_-14db9cf6_5a3bdf77_241 Long-Running-Action-Recovery: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8... Content-Length: 0 Host: localhost:8888 Connection: Keep-Alive {code} > Participants should not be told to compensate after completion > -------------------------------------------------------------- > > Key: JBTM-2977 > URL: https://issues.jboss.org/browse/JBTM-2977 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Nicola Ferraro > Assignee: Michael Musgrove > > When a LRA is closed the coordinator behaves incorrectly if a participant is slow to respond. > While the call to "/complete" is still ongoing, the coordinator (recovery module) may issue a second call to "/compensate", making it impossible for the participant to determine when a LRA is really closed. > The LRA coordinator must choose a single outcome for the LRA and be consistent with that (retrying until all participants are in status complete/failedtocomplete in this case). > A second minor problem is that the call to "/close" is synchronous, and the caller is kept attached forever if the participant does not respond to "/complete". It would be better to establish a timeout and return a "Completing" status if not all participant are done in time. > I attach few simple steps to reproduce it with shell commands. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2977) Participants should not be told to compensate after completion

by Nicola Ferraro (JIRA)

[ https://issues.jboss.org/browse/JBTM-2977?page=com.atlassian.jira.plugin.... ] Nicola Ferraro updated JBTM-2977: --------------------------------- Steps to Reproduce: {code} # # Shell 1: listen for connections (does not reply) and print output nc -kl 8888 # Shell 2: create a saga and close it COORDINATOR_URL=http://localhost:8080/lra-coordinator echo "Creating new LRA" LRA_URL=$(curl -X POST $COORDINATOR_URL/start | sed "s/\"//g") echo "Joining LRA" curl -X PUT $LRA_URL -d http://localhost:8888 echo "Close LRA" curl -X PUT $LRA_URL/close # Output of shell 1 Accept-Encoding: gzip, deflate Content-Type: application/json Long-Running-Action: http://localhost:8080/lra-coordinator/0_ffff0a2140b4_-14db9cf6_5a3bdf77_241 Long-Running-Action-Recovery: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8... Content-Length: 0 Host: localhost:8888 Connection: Keep-Alive ###### After some seconds, when periodic recovery starts ###### PUT /compensate HTTP/1.1 Accept-Encoding: gzip, deflate Content-Type: application/json Long-Running-Action: http://localhost:8080/lra-coordinator/0_ffff0a2140b4_-14db9cf6_5a3bdf77_241 Long-Running-Action-Recovery: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8... Content-Length: 0 Host: localhost:8888 Connection: Keep-Alive {code} was: # Shell 1: listen for connections (does not reply) and print output nc -kl 8888 # Shell 2: create a saga and close it COORDINATOR_URL=http://localhost:8080/lra-coordinator echo "Creating new LRA" LRA_URL=$(curl -X POST $COORDINATOR_URL/start | sed "s/\"//g") echo "Joining LRA" curl -X PUT $LRA_URL -d http://localhost:8888 echo "Close LRA" curl -X PUT $LRA_URL/close # Output of shell 1 Accept-Encoding: gzip, deflate Content-Type: application/json Long-Running-Action: http://localhost:8080/lra-coordinator/0_ffff0a2140b4_-14db9cf6_5a3bdf77_241 Long-Running-Action-Recovery: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8... Content-Length: 0 Host: localhost:8888 Connection: Keep-Alive ###### After some seconds, when periodic recovery starts ###### PUT /compensate HTTP/1.1 Accept-Encoding: gzip, deflate Content-Type: application/json Long-Running-Action: http://localhost:8080/lra-coordinator/0_ffff0a2140b4_-14db9cf6_5a3bdf77_241 Long-Running-Action-Recovery: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8... Content-Length: 0 Host: localhost:8888 Connection: Keep-Alive > Participants should not be told to compensate after completion > -------------------------------------------------------------- > > Key: JBTM-2977 > URL: https://issues.jboss.org/browse/JBTM-2977 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Nicola Ferraro > Assignee: Michael Musgrove > > When a LRA is closed the coordinator behaves incorrectly if a participant is slow to respond. > While the call to "/complete" is still ongoing, the coordinator (recovery module) may issue a second call to "/compensate", making it impossible for the participant to determine when a LRA is really closed. > The LRA coordinator must choose a single outcome for the LRA and be consistent with that (retrying until all participants are in status complete/failedtocomplete in this case). > A second minor problem is that the call to "/close" is synchronous, and the caller is kept attached forever if the participant does not respond to "/complete". It would be better to establish a timeout and return a "Completing" status if not all participant are done in time. > I attach few simple steps to reproduce it with shell commands. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2977) Participants should not be told to compensate after completion

by Nicola Ferraro (JIRA)

Nicola Ferraro created JBTM-2977: ------------------------------------ Summary: Participants should not be told to compensate after completion Key: JBTM-2977 URL: https://issues.jboss.org/browse/JBTM-2977 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.7.1.Final Reporter: Nicola Ferraro Assignee: Michael Musgrove When a LRA is closed the coordinator behaves incorrectly if a participant is slow to respond. While the call to "/complete" is still ongoing, the coordinator (recovery module) may issue a second call to "/compensate", making it impossible for the participant to determine when a LRA is really closed. The LRA coordinator must choose a single outcome for the LRA and be consistent with that (retrying until all participants are in status complete/failedtocomplete in this case). A second minor problem is that the call to "/close" is synchronous, and the caller is kept attached forever if the participant does not respond to "/complete". It would be better to establish a timeout and return a "Completing" status if not all participant are done in time. I attach few simple steps to reproduce it with shell commands. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2976) Make jdbc connection pools separate per db url

by Ondra Chaloupka (JIRA)

Ondra Chaloupka created JBTM-2976: ------------------------------------- Summary: Make jdbc connection pools separate per db url Key: JBTM-2976 URL: https://issues.jboss.org/browse/JBTM-2976 Project: JBoss Transaction Manager Issue Type: Enhancement Components: JTA Affects Versions: 5.7.1.Final Reporter: Ondra Chaloupka Assignee: Ondra Chaloupka As follow-up to issue https://issues.jboss.org/browse/JBTM-2972 discussed at https://github.com/jbosstm/narayana/pull/1269#issuecomment-352737031: when the Narayana pooling implementation is used then parameter `maxConnections` refers to all connections created by transactional driver. As an enhancement we should consider to count max connection pool per db url (aka. per datasource) not globally. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 11 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 updated JBTM-2955: -------------------------------- Issue Type: Bug (was: Enhancement) > 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: Bug > 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, 11 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 December 2017