[JBoss JIRA] (JBTM-2736) Enhance error log message on long node name to contain max node name length
by Ondra Chaloupka (JIRA)
Ondra Chaloupka created JBTM-2736:
-------------------------------------
Summary: Enhance error log message on long node name to contain max node name length
Key: JBTM-2736
URL: https://issues.jboss.org/browse/JBTM-2736
Project: JBoss Transaction Manager
Issue Type: Enhancement
Affects Versions: 5.3.4.Final
Reporter: Ondra Chaloupka
Assignee: Ondra Chaloupka
Priority: Minor
When maximal node identifier size is exceeded an exception and log message is shown. This message does not contain information what was the maximum of the node identifier length for user could easily adjust his setting based on that info.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[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:
--------------------------------
Summary: Allow in-flowed XAR to be scanned for Xid more than once between scans of the recovery system (was: XAR should be scanned more frequently for prepared transactions)
> 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, 8 months
[JBoss JIRA] (JBTM-2701) XAR should be scanned more frequently for prepared transactions
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2701?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2701:
-------------------------------------
This was believed to be the cause of the SF ticket but actually it was JBTM-2614
> XAR should be scanned more frequently for prepared transactions
> ---------------------------------------------------------------
>
> 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, 8 months
[JBoss JIRA] (JBTM-2733) Adding section about inflow transactions and EIS interaction
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2733?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka reassigned JBTM-2733:
-------------------------------------
Assignee: Tom Jenkinson
> Adding section about inflow transactions and EIS interaction
> ------------------------------------------------------------
>
> Key: JBTM-2733
> URL: https://issues.jboss.org/browse/JBTM-2733
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Documentation
> Affects Versions: 5.3.4.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
>
> I would like ask for enhancing Narayana documentation for section where information about inflow transactions and interaction with EIS would be part of.
> This ask for the addition came from discussion about behaviour of inflow transaction on jbossts mailing list. Particularly information how EIS and TM is expected to interoperate during recovery process. E.g. how EIS is expected to finish transaction when TM jvm crash occurs or how EIS is expected to finish transaction when participant of txn involved under management of TM (TM is manager of subordinate transaction) and such participant independently decides to rollback (after prepare is confirmed) which causes heuristic exception being thrown to EIS RAR and transaction is put to heuristic state.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka updated JBTM-2735:
----------------------------------
Component/s: JTA
JTS
> EIS can't finish all participants of inflow in-doubt transaction after jvm crash
> --------------------------------------------------------------------------------
>
> Key: JBTM-2735
> URL: https://issues.jboss.org/browse/JBTM-2735
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTA, JTS
> Affects Versions: 5.3.3.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
>
> When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.
> Expected flow of the case would be
> # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR
> # TM receives commit order by EIS RAR call {{XATerminator.commit}}
> # TM prepares both participants
> # end phase prepares, start phase commits
> # JVM crashes
> # app server is restarted again
> # EIS system repeats commit call as subordinate txn was not finished
> # TM calls commit on both participants to finish the transaction
> This scenario has two troubles in current implementation
> If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called.
> For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling.
> (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash
by Ondra Chaloupka (JIRA)
Ondra Chaloupka created JBTM-2735:
-------------------------------------
Summary: EIS can't finish all participants of inflow in-doubt transaction after jvm crash
Key: JBTM-2735
URL: https://issues.jboss.org/browse/JBTM-2735
Project: JBoss Transaction Manager
Issue Type: Bug
Reporter: Ondra Chaloupka
When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.
Expected flow of the case would be
# enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR
# TM receives commit order by EIS RAR call {{XATerminator.commit}}
# TM prepares both participants
# end phase prepares, start phase commits
# JVM crashes
# app server is restarted again
# EIS system repeats commit call as subordinate txn was not finished
# TM calls commit on both participants to finish the transaction
This scenario has two troubles in current implementation
If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called.
For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling.
(_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka reassigned JBTM-2735:
-------------------------------------
Assignee: Tom Jenkinson
> EIS can't finish all participants of inflow in-doubt transaction after jvm crash
> --------------------------------------------------------------------------------
>
> Key: JBTM-2735
> URL: https://issues.jboss.org/browse/JBTM-2735
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Affects Versions: 5.3.3.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
>
> When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.
> Expected flow of the case would be
> # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR
> # TM receives commit order by EIS RAR call {{XATerminator.commit}}
> # TM prepares both participants
> # end phase prepares, start phase commits
> # JVM crashes
> # app server is restarted again
> # EIS system repeats commit call as subordinate txn was not finished
> # TM calls commit on both participants to finish the transaction
> This scenario has two troubles in current implementation
> If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called.
> For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling.
> (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (JBTM-2735) EIS can't finish all participants of inflow in-doubt transaction after jvm crash
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2735?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka updated JBTM-2735:
----------------------------------
Affects Version/s: 5.3.3.Final
> EIS can't finish all participants of inflow in-doubt transaction after jvm crash
> --------------------------------------------------------------------------------
>
> Key: JBTM-2735
> URL: https://issues.jboss.org/browse/JBTM-2735
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Affects Versions: 5.3.3.Final
> Reporter: Ondra Chaloupka
> Assignee: Tom Jenkinson
>
> When EIS RAR manages inflow transaction through {{XATerminator}} calls and jvm of TM is crashed at the start of commit phase then EIS can't recover all transaction participants.
> Expected flow of the case would be
> # enlist two participants of inflow transaction - that means TM manages subordinate transaction and accepts orders from EIS RAR
> # TM receives commit order by EIS RAR call {{XATerminator.commit}}
> # TM prepares both participants
> # end phase prepares, start phase commits
> # JVM crashes
> # app server is restarted again
> # EIS system repeats commit call as subordinate txn was not finished
> # TM calls commit on both participants to finish the transaction
> This scenario has two troubles in current implementation
> If app server is restarted (after jvm crash happened) and EIS calls commit right after the start there is thrown {{XAER_RMFAIL}} when XATerminator.commit is called.
> For the commit have got a real effect on in-doubt transaciton there needs to be called recovery first. From that point in time the in-doubt inflow transaction is "available" for EIS RAR XATerminator.commit call. But there is another issue. Transaction was stopped with two participants prepared. But after commit is called from XATerminator only one XAResource is committed. The other one is left and forgotten. As the transaction itself is resolved as finished (thus removed from log store) there is no way to get to the remaining in-doubt participant - at least with help of jboss cli tooling.
> (_The reason could be that both XA resources shared the xid, as discussed in other place, TM does not rights to change xid and it needs to reuse existing one provided by EIS to all the work_)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (JBTM-2734) EIS can't recover transaction when heuristic outcome happens
by Ondra Chaloupka (JIRA)
Ondra Chaloupka created JBTM-2734:
-------------------------------------
Summary: EIS can't recover transaction when heuristic outcome happens
Key: JBTM-2734
URL: https://issues.jboss.org/browse/JBTM-2734
Project: JBoss Transaction Manager
Issue Type: Bug
Reporter: Ondra Chaloupka
Priority: Minor
For "a normal" transaction which is started and managed by transaction manager heuristic state is expected to be solved this way
# prepare phase successfully finishes, participant make a heuristic decision (ie. rollbacks) which causes that TM receives a XAException with error code as e.g. XA_RMERR or XA_HEURRB.
# transaction is marked to have heuristic result and manual intervention is necessary
# user calls {{recover}} for participant at such state and its state is changed to _prepared_
# replay of commit is called for the participant which causes to get commit called once again for the {{XAResource}} and participant record is removed from TM object store
This workflow does not work for inflow transaction where EIS is expected to order the TM to commit (as TM stands in position of subordinate transaction manager). The expected procedure should be
# EIS propagates EIS TX to Narayana
# enlisting XAR in Narayana subordinate TX
# committing EIS TX
## It commits Narayana subordinate TX
# XAR in Narayana TX returns RMERR
# Narayana returns XA_HEURMIX
# calling the Narayana tooling op {{recover}} to move the heuristic back to prepared
# EIS should not forget its TX where Narayana TX is a subordinate as we returned a heursitic so its not allowed to forget it yet
# EIS should call Narayana via XATerminator::recover()
## getting back an Xid that matches to Narayana subordinate TX
# EIS should try again to complete this Xid it sees fit according to its own recovery log, e.g. e.g. call XATerminator::commit(xid)
(_in the real world once an XAR had rolled back it would be unlikely to ever be able to commit again so it would be a bit synthetic to allow it commit so it would be up to you how you decide to complete the TX_)
The issue is that {{recover}} operation returns the state of participant to _prepared_ but EIS commit call (({{XATerminator.commit}}) does cause {{XAResource.commit}} being invoked and participant log being removed from the TM object store.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months