Uber Cadence任务列表管理

Question

我们正在使用Uber Cadence，并定期遇到生产环境方面的问题。设置如下：

• One Java 14与Cadence client 2.7.5
• Cadence service version 0.14.1与Postgres DB

有多个域，对于所有域，单个BE服务器都注册为工作人员。

在日志中可以看到的是，在查询过程中，韵律似乎失去了对BE服务的粘着性：

"msg":"query direct through matching failed on sticky, clearing sticky before attempting on non-sticky","service":"cadence-history","shard-id":1,"address":"10.1.1.111:7934"
"msg":"query directly though matching on non-sticky failed","service":"cadence-history","shard-id":1,"address":"10.1.1.111:7934"..."error":"code:deadline-exceeded message:timeout"
"msg":"query directly though matching on non-sticky failed","service":"cadence-history","shard-id":1,"address":"10.1.1.111:7934"..."error":"code:deadline-exceeded message:timeout"
"msg":"query directly though matching on non-sticky failed","service":"cadence-history","shard-id":1,"address":"10.1.1.111:7934"..."error":"code:deadline-exceeded message:timeout"
"msg":"query directly though matching on non-sticky failed","service":"cadence-history","shard-id":1,"address":"10.1.1.111:7934"..."error":"code:deadline-exceeded message:timeout"
...

同时，在后端，什么也看不见。但是，在此期间，如果我检查cadence客户机上的计票器，我会看到任务列表在那里，但它不再被视为决策处理程序(http://localhost:8088/domains/mydomain/task-lists/mytasklist/pollers)。由于这一点，整个环境已经死亡，因为没有任何东西可以在这个决定上取得进展。唯一的选择是重新启动后端服务，并让它重新注册为一个工作人员。

在这一点上，调查是卡住了，因此，一些帮助，将不胜感激。

• ，有人知道员工或任务列表如何失去作为决策处理程序的能力吗？它是否是由cadence管理的，比如基于工作人员生成的错误数？我没有找到任何关于这方面的信息。据我所知，当粘性丢失时，
• 会检查另一个工作人员是否重播工作流并继续它(在我的例子中，这将是同一个工作人员，因为只有一个工作人员)。是否有可能不可能重放流(虽然我认为它会在后端日志中从cadence客户端生成一些内容)，或者此时工作人员已经从列表中删除并导致超时？

任何帮助都是受欢迎的！谢谢!

Answer 1

是否有人知道工作人员或任务列表如何失去作为决策处理程序的能力？

当工作人员停止对决策任务的轮询时，就会发生这种情况。例如，如果您仅为活动任务配置员工轮询，那么它将显示为这样。因此，显然，如果由于某种原因，工人停止了对决策任务的轮询，也会发生这种情况。

正如我所理解的，当粘性丢失时，

将检查另一个工作人员是否重播工作流并继续。

是的，只要有另一个工作人员轮询决策任务。注意，查询任务被视为决策任务类型之一。(这是一个错误的设计，我们正在努力把它分开)。

从你的日志中：

"msg":"query directly though matching on non-sticky failed","service":"cadence-history","shard-id":1,"address":"10.1.1.111:7934"..."error":"code:deadline-exceeded message:timeout"

这意味着Cadence将查询任务分派给一个工作人员，而一个工作人员接受了，但没有在超时内返回。

很有可能在查询处理程序逻辑中存在一些bug。这个错误导致决策工作者崩溃(这意味着Cadence java客户端也有一个错误，用户代码崩溃不应该使工作人员崩溃)。然后对员工池的所有实例进行查询任务循环，最终使所有决策工作人员崩溃。