永无止境的启发式参与者定期恢复 [英] Never ending periodic recovery of heuristic participants

问题描述

几天来，我们的日志中已经塞满了该消息

For days our log has been full of this message

2018-06-15 12:19:23 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a983f1e:1f3aa2ff:5a09aa02:d1c08c has 1 heuristic participant(s)!
2018-06-15 12:19:23 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0a983f1e:1f3aa2ff:5a09aa02:d1c08c, node_name=acme_node, branch_uid=0:ffff0a983f1e:1f3aa2ff:5a09aa02:d1c08d, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@6569a57c >
2018-06-15 12:19:23 WARN [com.arjuna.ats.arjuna] (Periodic Recovery) Transaction 0:ffff0a983f1e:1f3aa2ff:5a09aa02:d1c08c restored heuristic participant XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=46, bqual_length=36, tx_uid=0:ffff0a983f1e:1f3aa2ff:5a09aa02:d1c08c, node_name=acme_node, branch_uid=0:ffff0a983f1e:1f3aa2ff:5a09aa02:d1c08d, subordinatenodename=null, eis_name=unknown eis name >, heuristic: TwoPhaseOutcome.FINISH_OK com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@6569a57c >

它总是相同的Xid.有办法解决吗?我们正在考虑正常关闭应用程序并删除data/tx-object-store中的文件.这是个好主意吗?

It is always the same Xid. Is there a way to solve this? We are considering gracefully shutting down the application and deleting the files in data/tx-object-store. Is this a good idea?

这是WildFly 11的一部分.我们已经使用Oracle 12c和IBM WebSphere MQ设置了XA事务.我们正在执行从消息驱动的Bean到JDBC的XA事务.

That's with WildFly 11. We have XA transactions set up with Oracle 12c and IBM WebSphere MQ. We are doing XA transactions from a message driven bean to JDBC.

推荐答案

我在

如果在事务协调器告诉XAResource提交之后但在更新事务日志以删除参与者之前，在事务环境中发生故障，则恢复将尝试重播提交.对于序列化XAResource，来自XAResource的响应将使参与者能够从日志中删除，并在所有参与者都已提交后最终将其删除.但是，如果XAResource是不可恢复的，那么任何XAResourceRecovery实例都极不可能为恢复子系统提供新的XAResource来尝试进行恢复；在这种情况下，恢复将继续失败，并且日志条目将永远不会被删除.

If a failure occurs in the transaction environment after the transaction coordinator had told the XAResource to commit but before the transaction log has been updated to remove the participant, then recovery will attempt to replay the commit. In the case of a Serialized XAResource, the response from the XAResource will enable the participant to be removed from the log, which will eventually be deleted when all participants have been committed. However, if the XAResource is not recoverable then it is extremely unlikely that any XAResourceRecovery instance will be able to provide the recovery sub-system with a fresh XAResource to use in order to attempt recovery; in which case recovery will continually fail and the log entry will never be removed.

有两个可能的解决方案:

There are two possible solutions to this problem:

依靠相关的ExpiryScanner最终将日志移到其他位置.然后将需要手动干预，以确保可以安全地删除日志.如果移动了日志条目，则将输出适当的警告消息.

Rely on the relevant ExpiryScanner to eventually move the log elsewhere. Manual intervention will then be needed to ensure the log can be safely deleted. If a log entry is moved, suitable warning messages will be output.

将com.arjuna.ats.jta.xaAssumeRecoveryComplete设置为true.每当无法从任何已注册的XAResourceRecovery实例中找到新的XAResource实例时，都会选中此选项.如果为false(默认值)，恢复将假定XAResourceRecovery实例存在暂时问题(例如，并非所有实例都已在子系统中注册)，并将定期尝试恢复.如果为true，则恢复将假定先前的提交尝试已成功，并且可以从日志中删除该实例，而无需进行进一步的恢复尝试.此选项是全局选项，因此请谨慎使用，因为如果使用不当，XAResource实例可能会保持未提交状态.

Set the com.arjuna.ats.jta.xaAssumeRecoveryComplete to true. This option is checked whenever a new XAResource instance cannot be located from any registered XAResourceRecovery instance. If false (the default), recovery assumes that there is a transient problem with the XAResourceRecovery instances (e.g., not all have been registered with the sub-system) and will attempt recovery periodically. If true then recovery assumes that a previous commit attempt succeeded and this instance can be removed from the log with no further recovery attempts. This option is global, so needs to be used with care since if used incorrectly XAResource instances may remain in an uncommitted state.

这篇关于永无止境的启发式参与者定期恢复的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！