共有1个答案
在大多数情况下，业务失败不需要恢复选项。
常见的模式是不断重试，直到下游依赖项可用。这是可能的，因为Temporal/Cadence没有系统对活动重试持续时间的限制。如果下游系统可以关闭几天，则可以连续重试几天。
如果由于某种原因，您希望在一段时间后停止重试，然后在外部信号上恢复它，则可以作为工作流逻辑的一部分实现，在某些类型的活动错误上，工作流会Hibernate以恢复外部信号。
-
我们希望建立一个工作流程，其中包含以下步骤，在这个顺序 执行一些同步活动。 通过kafka事件触发外部操作。 收听kafka事件以获取操作结果。 根据结果执行一些其他活动。 Kafka可能包含与工作流无关的事件，因此我们需要一个单独的工作流来过滤该特定工作流的事件。 使用cadence，我计划将它分成两个工作流程 < li >工作流程1 : 1 - 是否可以在不实际阻塞线程的情况下等待 workf
-
为用户可视化节奏工作流的最佳方式是什么？ 我想在一个高层次的视图中向用户展示工作流的不同步骤（类似于大多数食品配送应用程序的功能：下单- 我对向用户展示实际执行的节奏活动不感兴趣，因为我不希望他们看到我的工作流程的详细信息，我只想可视化他们感兴趣的某种高级阶段。 一种方法是保留工作流的高级描述，并在工作流代码本身内部进行状态转换（在启动活动 X 时将阶段 Y 标记为已启动等）。但是，我试图将这个问
-
将是什么 线程不足，无法执行工作流。如果此消息始终显示，请选择WorkerOptions。应减小maxConcurrentWorklfowExecutionSize或WorkerOptions。maxWorkflowThreads增加。 处于阻塞状态的工作流在内存中保持活动状态？？处于等待状态的工作流是否持续检查条件？？更多的 -
-
除了之外，还有其他方法可以发出工作流拒绝信号吗？ 基本上，我有一个工作流，它在超时前会定期继续运行。但是，如果它在继续像新的一样工作之前不断收到大量信号，它将会超时并丢失一些信号。我可以将< code > MaximumSignalsPerExecution 设置得更低，这样它就会在超时之前拒绝信号，但理想情况下，我希望能够在工作流级别进行配置。 我正在测试一些更糟糕的情况，其中存在流量峰值，并且
-
我正在运行节奏，卡桑德拉使用 docker run -e CASSANDRA_SEEDS=10.x.x.x e 超级数据库/服务器运行：。并成功运行。 Azure cosmos表示，任何运行在Cassandra上的系统都可以使用Azure cosmos，使用提供的cosmos cassandra APi，通过修改客户端连接创建代码，例如:GO app示例代码: Func Get会话（cosmosC
-
对于长时间运行的活动，我们可以使用心跳来通知活动是正在运行还是已死。 我们有一个工作流，该工作流调用多个子工作流，其中包含一些基于父工作流生成的分组的参数。子工作流是长时间运行的工作流。 有没有办法让类似的检测信号从子工作流发送，因为这些工作流长时间运行，超时设置为几个小时？或者更确切地说，通知子工作流正在运行的方法是什么？ 我们正在使用go-client来实现工作流程。