[JBoss JIRA] (JBTM-2751) Prevent JTS bottom-up recovery from rolling back prepared inflowed JCA transactions
by Ondra Chaloupka (JIRA)
Ondra Chaloupka created JBTM-2751:
-------------------------------------
Summary: Prevent JTS bottom-up recovery from rolling back prepared inflowed JCA transactions
Key: JBTM-2751
URL: https://issues.jboss.org/browse/JBTM-2751
Project: JBoss Transaction Manager
Issue Type: Bug
Components: JCA, JTS, Recovery
Reporter: Ondra Chaloupka
Assignee: Tom Jenkinson
Priority: Blocker
Fix For: 5.next
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, 7 months
[JBoss JIRA] (JBTM-2750) Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system
by Ondra Chaloupka (JIRA)
Ondra Chaloupka created JBTM-2750:
-------------------------------------
Summary: Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system
Key: JBTM-2750
URL: https://issues.jboss.org/browse/JBTM-2750
Project: JBoss Transaction Manager
Issue Type: Enhancement
Components: Transaction Core
Affects Versions: 4.17.33
Environment: JBoss EA P6.4.8
Reporter: Ondra Chaloupka
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, 7 months
[JBoss JIRA] (JBTM-2749) Add an SPI method to lookup imported transactions by Xid
by Michael Musgrove (JIRA)
Michael Musgrove created JBTM-2749:
--------------------------------------
Summary: Add an SPI method to lookup imported transactions by Xid
Key: JBTM-2749
URL: https://issues.jboss.org/browse/JBTM-2749
Project: JBoss Transaction Manager
Issue Type: Feature Request
Components: JCA, SPI
Affects Versions: 5.3.4.Final
Reporter: Michael Musgrove
Assignee: Michael Musgrove
When EJB remoting sees an incomming transaction it needs to determine whether it is one that the TM already knows about and should just resume it or if it needs to start a new subordinate transaction for it on this node.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[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.... ]
Issue was automatically transitioned when Tom Jenkinson created pull request #1066 in GitHub
--------------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Open)
> 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.next
>
>
> 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, 7 months
[JBoss JIRA] (JBTM-2748) Prevent JTS bottom-up recovery from rolling back prepared inflowed JCA transactions
by Tom Jenkinson (JIRA)
Tom Jenkinson created JBTM-2748:
-----------------------------------
Summary: 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.next
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, 7 months
[JBoss JIRA] (JBTM-2122) Go through JTS code and compare/contrast with capabilities missing in other dist tx code we've got
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2122?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2122:
-------------------------------------
Observation: when a transaction that is using JTS with JCA in-flow crashes after writing the prepare message, a subsequent XATerminator::commit() message is not sufficient to flush the xa_commit to enlisted XAR. This is different from JTA because we can't know if the TX is making slow progress or it's a genuine recovery scenario.
For these types of application the follow is expected:
XATerminator::prepare(xid1)
CRASH
xid1 = XATerminator::recover()
XATerminator::commit(xid1)
Then, in the JVM where the resource lives:
periodicRecoveryScan()
// Wait for orphan detection interval
periodicRecoveryScan()
The second periodicRecoveryScan will effect bottom-up recovery on the XAR and it will try to contact the potentially remote coordinator to ask the state of the transaction (which will be of state committing)
> Go through JTS code and compare/contrast with capabilities missing in other dist tx code we've got
> --------------------------------------------------------------------------------------------------
>
> Key: JBTM-2122
> URL: https://issues.jboss.org/browse/JBTM-2122
> Project: JBoss Transaction Manager
> Issue Type: Task
> Components: JTS
> Affects Versions: 5.0.1
> Reporter: Mark Little
> Assignee: Michael Musgrove
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (JBTM-2746) facing performane issue when setup narayana JTA and txbridge out of JBoss
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2746?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2746:
-------------------------------------
Thanks!
> facing performane issue when setup narayana JTA and txbridge out of JBoss
> -------------------------------------------------------------------------
>
> Key: JBTM-2746
> URL: https://issues.jboss.org/browse/JBTM-2746
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: JTA, TxBridge, XTS
> Affects Versions: 5.3.4.Final
> Reporter: Zefa Guan
> Assignee: Gytis Trikleris
> Attachments: ServiceA_logs.zip, ServiceB_logs.zip, ServiceC_logs.zip
>
>
> when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario;
> 1) running 3 tomcat instances
> 2) A call B via WS
> 3) B call C via WS
> 4) when 100 - 200 GET query from " http://localhost:8081/user?action=add " via Service A, all 3 tomcat got stuck for a while then raise exception with attached logs
> sth similar with quickstart example but no EJB and out of JBoss from https://github.com/jbosstm/quickstart/tree/master/XTS
> ==================================================
> WS-AT to JTA (Multi Hop)
> This example demonstrates a JTA client that invokes a remote EJB over Web services. The JTA transaction is distributed to the remote EJB using WS-AtomicTransaction. The service also acts as a client to a second service. Again using WS-AT to distribute the transaction over Web services.
> ==================================================
> {code}
> servlet client - localhost:8081/user?action=add
> |
> --------------------------------------------------------------
> ServiceA Tomcat
> Narayana JTA
> Webservie - localhost:8082/user?action=add
> --------------------------------------------------------------
> |
> txbridge
> |
> --------------------------------------------------------------
> ServiceB Tomcat
> Narayana JTA
> Webservie - localhost:8083/user?action=add
> --------------------------------------------------------------
> |
> txbridge
> |
> --------------------------------------------------------------
> ServiceB Tomcat
> Narayana JTA
> --------------------------------------------------------------
> {code}
> ---------------------------------------------
> this may caused by race condition/socket timeout/exceed limits, will need to reproduce and research more;
> at the beginning I thought it was caused by DB resource locking failed but after I commented out all DB access, the problem still there
> put all my code to https://github.com/JonkeyGuan/txbridgeInTomcat8 for reproducing and reference
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (JBTM-2746) facing performane issue when setup narayana JTA and txbridge out of JBoss
by Zefa Guan (JIRA)
[ https://issues.jboss.org/browse/JBTM-2746?page=com.atlassian.jira.plugin.... ]
Zefa Guan commented on JBTM-2746:
---------------------------------
sure, post https://developer.jboss.org/message/962385#962385
> facing performane issue when setup narayana JTA and txbridge out of JBoss
> -------------------------------------------------------------------------
>
> Key: JBTM-2746
> URL: https://issues.jboss.org/browse/JBTM-2746
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: JTA, TxBridge, XTS
> Affects Versions: 5.3.4.Final
> Reporter: Zefa Guan
> Assignee: Gytis Trikleris
> Attachments: ServiceA_logs.zip, ServiceB_logs.zip, ServiceC_logs.zip
>
>
> when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario;
> 1) running 3 tomcat instances
> 2) A call B via WS
> 3) B call C via WS
> 4) when 100 - 200 GET query from " http://localhost:8081/user?action=add " via Service A, all 3 tomcat got stuck for a while then raise exception with attached logs
> sth similar with quickstart example but no EJB and out of JBoss from https://github.com/jbosstm/quickstart/tree/master/XTS
> ==================================================
> WS-AT to JTA (Multi Hop)
> This example demonstrates a JTA client that invokes a remote EJB over Web services. The JTA transaction is distributed to the remote EJB using WS-AtomicTransaction. The service also acts as a client to a second service. Again using WS-AT to distribute the transaction over Web services.
> ==================================================
> {code}
> servlet client - localhost:8081/user?action=add
> |
> --------------------------------------------------------------
> ServiceA Tomcat
> Narayana JTA
> Webservie - localhost:8082/user?action=add
> --------------------------------------------------------------
> |
> txbridge
> |
> --------------------------------------------------------------
> ServiceB Tomcat
> Narayana JTA
> Webservie - localhost:8083/user?action=add
> --------------------------------------------------------------
> |
> txbridge
> |
> --------------------------------------------------------------
> ServiceB Tomcat
> Narayana JTA
> --------------------------------------------------------------
> {code}
> ---------------------------------------------
> this may caused by race condition/socket timeout/exceed limits, will need to reproduce and research more;
> at the beginning I thought it was caused by DB resource locking failed but after I commented out all DB access, the problem still there
> put all my code to https://github.com/JonkeyGuan/txbridgeInTomcat8 for reproducing and reference
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (JBTM-2746) facing performane issue when setup narayana JTA and txbridge out of JBoss
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2746?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson reassigned JBTM-2746:
-----------------------------------
Assignee: Gytis Trikleris
> facing performane issue when setup narayana JTA and txbridge out of JBoss
> -------------------------------------------------------------------------
>
> Key: JBTM-2746
> URL: https://issues.jboss.org/browse/JBTM-2746
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: JTA, TxBridge, XTS
> Affects Versions: 5.3.4.Final
> Reporter: Zefa Guan
> Assignee: Gytis Trikleris
> Attachments: ServiceA_logs.zip, ServiceB_logs.zip, ServiceC_logs.zip
>
>
> when setup txbridge under Tomcat8 out of JBoss, I am facing performance issue as below scenario;
> 1) running 3 tomcat instances
> 2) A call B via WS
> 3) B call C via WS
> 4) when 100 - 200 GET query from " http://localhost:8081/user?action=add " via Service A, all 3 tomcat got stuck for a while then raise exception with attached logs
> sth similar with quickstart example but no EJB and out of JBoss from https://github.com/jbosstm/quickstart/tree/master/XTS
> ==================================================
> WS-AT to JTA (Multi Hop)
> This example demonstrates a JTA client that invokes a remote EJB over Web services. The JTA transaction is distributed to the remote EJB using WS-AtomicTransaction. The service also acts as a client to a second service. Again using WS-AT to distribute the transaction over Web services.
> ==================================================
> {code}
> servlet client - localhost:8081/user?action=add
> |
> --------------------------------------------------------------
> ServiceA Tomcat
> Narayana JTA
> Webservie - localhost:8082/user?action=add
> --------------------------------------------------------------
> |
> txbridge
> |
> --------------------------------------------------------------
> ServiceB Tomcat
> Narayana JTA
> Webservie - localhost:8083/user?action=add
> --------------------------------------------------------------
> |
> txbridge
> |
> --------------------------------------------------------------
> ServiceB Tomcat
> Narayana JTA
> --------------------------------------------------------------
> {code}
> ---------------------------------------------
> this may caused by race condition/socket timeout/exceed limits, will need to reproduce and research more;
> at the beginning I thought it was caused by DB resource locking failed but after I commented out all DB access, the problem still there
> put all my code to https://github.com/JonkeyGuan/txbridgeInTomcat8 for reproducing and reference
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months