September 2016 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2753) Method end on PGXAConnection has been called twice

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2753?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2753. ------------------------------- > Method end on PGXAConnection has been called twice > -------------------------------------------------- > > Key: JBTM-2753 > URL: https://issues.jboss.org/browse/JBTM-2753 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JTS > Affects Versions: 5.3.0.Final > Environment: Wildfly 8 > Reporter: Florian Mélot > Assignee: Tom Jenkinson > Priority: Minor > Fix For: 5.3.5.Final > > > End method from PGXAConnection has been called twice when an EJB called another EJB to get data from psql database (9.2.5) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2748) Prevent JTS bottom-up recovery from rolling back prepared inflowed JCA transactions

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2748?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2748. ------------------------------- > Prevent JTS bottom-up recovery from rolling back prepared inflowed JCA transactions > ----------------------------------------------------------------------------------- > > Key: JBTM-2748 > URL: https://issues.jboss.org/browse/JBTM-2748 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: JCA, JTS, Recovery > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Priority: Blocker > Fix For: 5.3.5.Final > > > There exists a defect that if a recovering JVM does the following steps: > doRecoveryScan() > waitForOrphanInterval() > doRecoveryScan() > *Before* XATerminator::recover is called in the root coordinator then bottom-up recovery will be told there is NoTransaction which is infers as a rollback. > I saw two options, one was to have TransactionCacheItem try to peek in the objectstore for ServerTransaction/JCA classes. The alternative is to add a new recovery module that can load the ServerTransaction/JCA classes periodically so the transaction won't be lost. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2744) Warning message show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2744?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2744. ------------------------------- > Warning message show with the mdb BlacktieStompAdministrationService and BlacktieAdminServiceXATMI > -------------------------------------------------------------------------------------------------- > > Key: JBTM-2744 > URL: https://issues.jboss.org/browse/JBTM-2744 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: BlackTie > Reporter: Amos Feng > Assignee: Amos Feng > Priority: Minor > Fix For: 5.3.5.Final > > > The warning message are > {code} > 00:06:48,719 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 69) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieStompAdministrationService message-driven bean. It will be handled as NOT_SUPPORTED. > 00:06:48,721 WARN [org.jboss.as.ejb3] (ServerService Thread Pool -- 67) WFLYEJB0485: Transaction type NEVER is unspecified for the onMessage method of the BlacktieAdminServiceXATMI message-driven bean. It will be handled as NOT_SUPPORTED. > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2701) Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2701: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done PR was merged > Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system > --------------------------------------------------------------------------------------------- > > Key: JBTM-2701 > URL: https://issues.jboss.org/browse/JBTM-2701 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Affects Versions: 4.17.33 > Environment: JBoss EA P6.4.8 > Reporter: Tom Ross > Assignee: Michael Musgrove > Priority: Minor > Fix For: 5.next > > > The JCA getNewXAResource() call can only bring forward the scanning of XAResources once per recovery pass (i.e. once every two minutes per default). > The following signature can be observed in the log file: > {noformat} > 2016-06-28 12:18:33,068 TRACE [com.arjuna.ats.jta] (EJB default - 98) XAResourceRecord.topLevelCommit for XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra >, heuristic: TwoPhaseOutcome.FINISH_OK, product: com/ecim/1.0, jndiName: java:/eis/custom-ra com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@64fa6d0e >, record id=0:ffff0af7f663:ba85fe7:57714e42:7058f3 > 2016-06-28 12:18:33,068 WARN [com.arjuna.ats.jta] (EJB default - 98) ARJUNA016038: No XAResource to recover < formatId=131077, gtrid_length=40, bqual_length=48, tx_uid=0:ffff0af7f615:19718dac:576e895c:d7da9, node_name=svc_1_cmserv, branch_uid=0:ffff0af7f663:ba85fe7:57714e42:7058f2, subordinatenodename=svc_2_mscmce, eis_name=java:/eis/custom-ra > > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) BasicAction.doCommit for 0:ffff0af7f663:ba85fe7:57714e42:705303 received TwoPhaseOutcome.FINISH_ERROR from class com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord > 2016-06-28 12:18:33,069 TRACE [com.arjuna.ats.arjuna] (EJB default - 98) RecordList::insert(RecordList: empty) : appending /StateManager/AbstractRecord/XAResourceRecord for 0:ffff0af7f663:ba85fe7:57714e42:7058f3 > {noformat} > It would be useful to allow the getNewXAResource() call to re-scan XAR in case it is called in between recovery scans multiple times. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2760) SPI to check if JTA or JTS transaction is active during graceful shutdown

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2760?page=com.atlassian.jira.plugin.... ] Gytis Trikleris commented on JBTM-2760: --------------------------------------- WildFly service exposes JBossXATerminator and it needs to be casted to ExtendedJBossXATerminator. We should add a new service which would expose ExtendedJBossXATerminator, but that doesn't require any changes in the SPI. > SPI to check if JTA or JTS transaction is active during graceful shutdown > ------------------------------------------------------------------------- > > Key: JBTM-2760 > URL: https://issues.jboss.org/browse/JBTM-2760 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: SPI > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Critical > > During graceful shutdown EJB subsystem should check with transaction subsystem if request should be allowed in. Only requests participating in an existing transaction are permitted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2760) SPI to check if JTA or JTS transaction is active during graceful shutdown

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2760?page=com.atlassian.jira.plugin.... ] Gytis Trikleris closed JBTM-2760. --------------------------------- Resolution: Rejected Apparently this can already be achieved by using current SPI https://github.com/jbosstm/jboss-transaction-spi/blob/master/src/main/jav.... In WildFly it can be injected with this name https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java... > SPI to check if JTA or JTS transaction is active during graceful shutdown > ------------------------------------------------------------------------- > > Key: JBTM-2760 > URL: https://issues.jboss.org/browse/JBTM-2760 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: SPI > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Critical > > During graceful shutdown EJB subsystem should check with transaction subsystem if request should be allowed in. Only requests participating in an existing transaction are permitted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2760) SPI to check if JTA or JTS transaction is active during graceful shutdown

by Gytis Trikleris (JIRA)

[ https://issues.jboss.org/browse/JBTM-2760?page=com.atlassian.jira.plugin.... ] Work on JBTM-2760 started by Gytis Trikleris. --------------------------------------------- > SPI to check if JTA or JTS transaction is active during graceful shutdown > ------------------------------------------------------------------------- > > Key: JBTM-2760 > URL: https://issues.jboss.org/browse/JBTM-2760 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: SPI > Reporter: Gytis Trikleris > Assignee: Gytis Trikleris > Priority: Critical > > During graceful shutdown EJB subsystem should check with transaction subsystem if request should be allowed in. Only requests participating in an existing transaction are permitted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2760) SPI to check if JTA or JTS transaction is active during graceful shutdown

by Gytis Trikleris (JIRA)

Gytis Trikleris created JBTM-2760: ------------------------------------- Summary: SPI to check if JTA or JTS transaction is active during graceful shutdown Key: JBTM-2760 URL: https://issues.jboss.org/browse/JBTM-2760 Project: JBoss Transaction Manager Issue Type: Feature Request Components: SPI Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Critical During graceful shutdown EJB subsystem should check with transaction subsystem if request should be allowed in. Only requests participating in an existing transaction are permitted. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2480) Provide documentation of how to integrate with Karaf

by Amos Feng (JIRA)

[ https://issues.jboss.org/browse/JBTM-2480?page=com.atlassian.jira.plugin.... ] Amos Feng updated JBTM-2480: ---------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Provide documentation of how to integrate with Karaf > ---------------------------------------------------- > > Key: JBTM-2480 > URL: https://issues.jboss.org/browse/JBTM-2480 > Project: JBoss Transaction Manager > Issue Type: Sub-task > Components: Documentation > Reporter: Tom Jenkinson > Assignee: Amos Feng > Priority: Minor > Fix For: 5.next > > > This should include recovery information -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2728) Add a forget operation to the tooling

by Michael Musgrove (JIRA)

[ https://issues.jboss.org/browse/JBTM-2728?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Michael Musgrove created pull request #1074 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Add a forget operation to the tooling > ------------------------------------- > > Key: JBTM-2728 > URL: https://issues.jboss.org/browse/JBTM-2728 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Components: Tooling > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Fix For: 5.next > > > The tooling provides two features for dealing with heuristic participants: > * a recover command that will move it back into the prepared state if the admin thinks a second prepare attempt is likely to succeed; > * a delete operation if the admin thinks it safe to do so; > > In the case of XA resources we also need a forget operation which will trigger the resource adaptor to clean up its end instead of relying on the admin to use tooling provided by the RA to clean up. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

7 years, 6 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 September 2016