Question

我有5个节点和1个公证节点Corda专用网络，以及一个具有UI和RESTful服务的Web客户端。

有许多状态及其属性由用户使用UI管理。我需要了解如何处理超时并避免多次更新或错误

场景1

用户正在查看某个功能的特定未消耗状态。
用户执行编辑并更新状态

收到请求的RESTful组件后，请使用CORDA RPCClient启动流程。它设置超时值，例如2秒

CORDA流运行已配置的规则，并且必须同步/收集来自所有参与节点的签名（4）。完整的处理需要2秒钟以上的时间（某些文件处理，多个状态更新等。我可以根据特定的用例将超时更改为更高的值。它肯定可以随时发生。需要了解建议的处理方式）

由于花费的时间比提供的时间长，CORDA RPCClient会引发异常。对于RESTFul服务/用户事务失败。

CORDA在后台处理和收集签名并更新节点。从CORDA的角度来看，一切看起来都很好，更改过的集将提交到分类帐。

问题：

是否有一种方法可以知道正在提交的事务，因此RESTful服务应该等待
如果用户再次提交，我们会检查交易哈希是否是与未消费状态相关联的最新哈希，如果不是，则拒绝交易（哈希是在查询时提供给UI的。
任何推荐的处理方式。

方案2

用户正在查看功能的特定未消耗状态。
用户执行编辑并更新状态

收到请求的RESTful组件后，请使用CORDA RPCClient启动流程。它设置超时值，例如2秒

CORDA流运行已配置的规则，并且必须同步/收集来自所有参与节点的签名（4）。节点之一已关闭或无法访问。流挂起/等待该节点重新启用。

RESTFul服务/ UI收到超时异常。用户刷新视图并再次提交更改。查询当前节点将返回旧数据，用户将尝试再次进行更改并提交。同样会发生在CORDA层上的事务将处于最新的未消耗状态（比较状态为未提交的tx哈希，它将继续进行，并将挂起/等待该节点再次处于活动状态。它等待了很长时间我一直在等待一分钟它没有尝试。

现在，该节点启动，并将与同级同步。公证人将给出例外，因为有两个状态/请求待处理以形成链中的下一个状态。交易失败。

问题：

是否有一种方法可以知道正在提交的事务，因此RESTful服务应该等待
任何推荐的处理方式。
是否可以提供用于节点通信的超时值。
我是否需要继续监视节点是否处于活动状态，并相应地调整用户体验。

感谢上述问题的所有帮助和支持。请让我知道是否需要其他信息。

Answer 1

超时

从Corda 3.3开始，无法在Corda RPC请求，流或到另一个节点的消息上设置超时。如果在尝试作为流的一部分与另一个节点联系时发生故障，则该消息将仅保留在出站消息队列中，直到可以成功传递为止。

检查流程进度

每个流都有唯一的运行ID。当您通过RPC（例如，使用CordaRPCOps.startFlowDynamic）启动流程时，您将获得一个FlowHandle。然后可以通过FlowHandle.id获得该流的唯一运行ID。拥有此ID后，可以通过检查流是否仍在当前状态机（即流）列表中来检查该流是否仍在进行中：

val flowInProgress = flowHandle.id in cordaRPCOps.stateMachinesSnapshot().map { it.id }

您还可以监视状态机管理器以等待流程完成，然后获得其结果：

val flowUpdates = cordaRPCOps.stateMachinesFeed().updates
flowUpdates.subscribe {
    if (it.id == flowHandle.id && it is StateMachineUpdate.Removed) {
        val int = it.result.getOrThrow()
        // Handle result.
    }
}

处理重复的请求

如果您尝试两次使用同一状态，或者在查询保管库以检索状态时或尝试对事务进行公证时，流程都会引发异常。我建议让用户重新开始流程，然后适当地处理任何双重花费的错误，并将其反映在前端（例如，通过错误消息和自动刷新）。

处理RPC和节点间通信超时

1 个答案: