NEAR localnet 上的大量重试和事务已过期

Posted

技术标签:

【中文标题】NEAR localnet 上的大量重试和事务已过期【英文标题】:Lots of retries and transaction expired on NEAR localnet 【发布时间】:2021-11-09 23:31:42 【问题描述】:

我们创建了一个在计算机上本地运行的测试链,启动了一个包含 4 个验证器的链(非常类似于 localnet),然后我们正在部署一个智能合约来测试链的各个方面(失败的交易、异步收据、args 编码、日志等)。

一切都可以在这里运行/查看https://github.com/streamingfast/battlefield-near(这是一组有助于运行此网络和交易的脚本)。

当我部署我的合约时,它总是需要重试 2 到 3 次才能让交易正确通过。不仅如此,我会说在 33% 的情况下,我会达到重试限制并收到 Transaction Expired 错误。

这对我来说似乎很奇怪,假设一切都在我的计算机上本地运行,部署合约需要如此多的重试。部署合约时,它是唯一进入的交易,因此不应该涉及拥塞(实际上应该根本没有流量)。

合约部署如何在不重试且交易永不过期的情况下立即通过?

【问题讨论】:

【参考方案1】:

网络可能太快了,正如您所提到的,它是一个单节点本地网络。这可能会导致事务快速过期,特别是考虑到我认为 localnet 上的默认过期值非常小。检查您的 genesis.json 中的 transaction_validity_period 并查看将其设置为较大的数字是否有帮助。

【讨论】:

这是一个 4 节点网络,而不是单节点网络。 “最坏”的情况是交易到期,问题更多:为什么交易需要多次广播,这个缺陷是一致的,就像我从未见过部署通过第一枪的合约一样。 transaction_validity_period 设置为 100,每秒 2 个块,这给了 30 秒。我希望它永远不会在本地网络上超时。重试错误是Retrying request to broadcast_tx_commit`,因为它已超时`。在成功之前平均要重试 1 到 2 次。 创世纪可以在这里看到github.com/streamingfast/battlefield-near/blob/master/boot/…。如果您有其他调整建议,我全力以赴。

以上是关于NEAR localnet 上的大量重试和事务已过期的主要内容,如果未能解决你的问题,请参考以下文章

dubbo超时重试和异常处理

rabbitmq~消息失败后重试达到 TTL放到死信队列(事务型消息补偿机制)

执行块的最长时间............带有重试和中间延迟

如何在断路器中添加重试和自定义恢复方法 - 功能性 java

Spring Boot Cloud + Ribbon + Feign + Hystrix + Zookeeper:重试和失败是怎么回事?

AWS 中的错误重试和指数退避 Error Retries and Exponential Backoff in AWS