[jbossts-issues] [JBoss JIRA] (JBTM-3216) Narrow the default recovery configuration in the jbossts-properties.xml files

[ https://issues.jboss.org/browse/JBTM-3216?page=com.atlassian.jira.plugin.... ] Ondrej Chaloupka commented on JBTM-3216: ---------------------------------------- To summarize the available orphan filters in the Narayana code base, they are: XAResourceOrphanFilter (com.arjuna.ats.jta.recovery) {{JTANodeNameXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - **it works only for JTA**, otherwise ABSTAIN (JTS is not processed as JTS does not work with orphan filters (https://issues.jboss.org/browse/JBTM-2124)). If JTA it checks if the {{Xid}}'s nodename matches the node id defined at the Narayana TM (This is required, otherwise TM may start to rollback transaction which should be committed by different TM instance.). For the node name checki it calls directly the {{NodeNameXAResourceOrphanFilter}} {{NodeNameXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - verifies that the {{Xid}} was created with this current Narayana TM by checking the node id of the TM. It's called by {{JTANodeNameXAResourceOrphanFilter}} {{InboundBridgeRecoveryManager (org.jboss.jbossts.txbridge.inbound)}} - only for XTS {{JTATransactionLogXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - **it works only for JTA**, otherwise ABSTAIN. If the there is a log record in the object store then abstaining to rollback this remote {{Xid}}. If there is a object store record then we expect the Xid will be committed by top-down processing or it's heuristics and it can be roll-back neither. {{SubordinationManagerXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - **it works only for JTA**, otherwise ABSTAIN. If the subordinate transaction is in-flight then it forces for it not being rolled-back. {{InboundBridgeOrphanFilter (org.jboss.narayana.rest.bridge.inbound)}} - only for XTS. Checks if there is no log record in the object store for not rolling-back an transaction which is expected to be commited during top-down recovery. {{JTAActionStatusServiceXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - **it works only for JTA**, otherwise ABSTAIN. It vetoes roll-back when there is an in-flight transaction for the found {{Xid}}. {{SubordinateJTAXAResourceOrphanFilter (com.arjuna.ats.internal.jta.recovery.arjunacore)}} - checks if the TM as subordinate TM is responsible for this transaction (the {{Xid}} subordinate matches with the TM node identifier). If the TM is responsible and there is no transaction log in the object store then it's considered the remote {{Xid}} is subordinate orphaned and it's rolled-back. -- This message was sent by Atlassian Jira (v7.13.8#713008)