0

Uber Cadence を使用していますが、定期的に本番環境で問題が発生します。セットアップは次のとおりです。

  • 1 つの Java 14 BE と Cadence クライアント 2.7.5
  • Postgres DB を使用するケイデンス サービス バージョン 0.14.1

複数のドメインがあり、すべてのドメインに対して単一の 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"
...

その間、バックエンドでは何も見えません。ただし、この間にケイデンス Web クライアントでポーラーを確認すると、タスク リストが表示されますが、決定ハンドラーとは見なされなくなります (http://localhost:8088/domains/mydomain/task-リスト/mytasklist/ポーラー)。このため、決定を進めることができるものがないため、環境全体がほとんど死んでいます。唯一のオプションは、バックエンド サービスを再起動し、ワーカーとして再登録することです。

この時点で調査が行き詰まっているため、何らかの助けをいただければ幸いです。

  • ワーカーまたはタスク リストが意思決定ハンドラーとしての能力を失う可能性があることを知っている人はいますか? ワーカーが生成したエラーの数に基づくなど、ケイデンスによって管理されていますか? これについては何も見つかりませんでした。
  • 粘着性が失われると理解できるように、ケイデンスは別のワーカーがワークフローを再生して続行するかどうかを確認します (私の場合、これは 1 つしかないため、同じワーカーになります)。フローを再生できない可能性はありますか (ケイデンス クライアントからのバックエンド ログに何かが生成されると思いますが)、またはその時点でワーカーがリストから既に削除されているためにタイムアウトが発生する可能性はありますか?

どんな助けでも大歓迎です！ありがとう！

4

1 に答える 1

0

ワーカーまたはタスク リストが意思決定ハンドラーとしての能力を失う方法を知っている人はいますか

これは、ワーカーが決定タスクのポーリングを停止したときに発生します。たとえば、アクティビティ タスクのワーカーのみのポーリングを構成すると、そのように表示されます。したがって、何らかの理由でワーカーが決定タスクのポーリングを停止した場合にも発生するようです。

粘着性が失われると理解したように、ケイデンスは別のワーカーがワークフローを再生して続行することを確認します

はい、決定タスクをポーリングする別のワーカーが存在する限り。クエリ タスクは、決定タスクの種類と見なされることに注意してください。(これは間違ったデザインです。分離する作業を進めています)。

ログから:

"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 がクエリ タスクをワーカーにディスパッチし、ワーカーが受け入れたが、タイムアウト内に応答しなかったことを意味します。

クエリ ハンドラー ロジックにバグがある可能性が非常に高いです。このバグにより、意思決定ワーカーがクラッシュしました (つまり、Cadence Java クライアントにもバグがあり、ユーザー コードのクラッシュによってワーカーがクラッシュすることはありません)。そして、ワーカー プールのすべてのインスタンスに対するクエリ タスク ループが、最終的にすべての意思決定ワーカーをクラッシュさせました。

于 2021-04-21T20:27:36.590 に答える