Camunda BPMでDeadlockを書くことができますか？そして私はできる

いくつかの時間前、私は書いた CamundaにIBM BPMからの移行が成功について、そして今、私たちの生活は幸せで快適な感想がいっぱいです。カムンダは失望することなく、このBPMエンジンとの友情を続けています。



しかし、悲しいかな、カムンダは不快な驚きをもたらす可能性があります。そのため、最も明白な結果が得られない場合があります。この記事では、その単純さにもかかわらず、一見したところよりも興味深く、やや複雑であることが判明した1つのケースを検討します。

私たちは猫を訓練します

問題を説明するために、総合的な例を考えます。クライアントベースを拡大することを決定し、猫と猫にサービスを提供する必要があるとしましょう。すべての潜在的なクライアントをチェックし、おそらく何かをすぐに提供する必要があります。



候補者の信頼性と候補者が提供できるサービスを確認します。信頼性チェックと可能なサービスは、いかなる方法でも関連付けられていません。これらのアクションは並行して実行できます。概略的には、bpmn図では、次のようになります。





図1.ふわふわのサービス



の概略プロセスこの図は、ゲートウェイの分岐と収集（結合）の主な手順を概略的に示しています。





このアイコンは並列ゲートウェイを表します。Parallel Gatewayは、プロセスの並列部分を構築するための最も簡単なゲートウェイです。



並列ゲートウェイには次の2つのタイプがあります。

• fork-ブランチごとに個別の実行を作成します。
• join-すべての着信実行が完了するのを待ちます。

実行 -（ドキュメントから）プロセスインスタンスの「実行パス」を表します。つまり、それはプロセスの実行のスレッドです。



次に、タスクを少し複雑にします。サービスの確認と検索は次の方法で行います。最初にクライアントの状態を確認し、次にクライアントに適したサービスを確認して、いくつかの前処理を行います。さらに、いくつかのサービスは一度にクライアントに適している可能性があるため、すべてのサービスをクライアントに提供できるはずです。



私たちは毛皮で覆われたクライアントと協力するので、バレリアン、クローレーキ、マスターの枕、その他の便利なサービスが適切です。





グラフ2.洗練されたFluffyカスタマーサービスグラフ



プロセスの新しいバージョンは次のようになります。このプロセスは、信頼性の検証と可能な提案の検索と並行しています。検索も並列化されます。この場合、対応する条件が満たされるブランチが実行されます。



条件との並列化では、包括的ゲートウェイが使用され、次のアイコンで示されます。





包括的ゲートウェイは、分岐条件を持つ並列ゲートウェイです。条件が真である分岐が実行されます。



ゲートウェイには2つのタイプがあります。

• fork-条件が満たされた各ブランチについて、実行が作成されます。これは、Parallel Gatewayでの実行と同じ方法で並列に実行されます。
• 並列ゲートウェイとは異なり、joinはすべてのブランチではなく、条件がtrueであるブランチのみの実行を待機します。

実行されたチェックが不十分であり、クライアントを再度チェックする必要がある場合があります。これを行うには、我々は非常に初めに再検証のために送信することができますすべてのチェック、の終わりに条件を追加





ダイアグラム3.動作するはずプロセスの最終版



それは面倒でしたが、このプロセスは、問題を解決します。

何？どうした？

ここで奇妙なことが起こり始めます。信頼性検証ブランチが実行され、収集並列ゲートウェイに到達します。これまでのところ、すべて順調です。



2番目のブランチは材料の状態をチェックし、結果に応じて、対応するタスクが実行されます。次に、プロセスは包括的ゲートウェイを収集するゲートウェイで停止し、それ以上移動しません。Coockpit（Kamundaの管理パネル）を見ると、実行は収集インクルーシブゲートウェイとパラレルゲートウェイでハングします。





図4.サービスプロセスのスタックジョブは



完了しました。Camundaのプロセスでデッドロックが発生したと言えます。この場合、並列プログラミングの理論からのデッドロックとデッドロックには直接関係しません。

̶̶̶̶̶̶̶̶̶̶̶̶の答えを求めて

何が起こったのか、なぜプロセスが停止したのかを十分に理解していないため、問題を経験的に解決する必要がありました。



おそらく、包括的ゲートウェイのデフォルトブランチが必要です。それがないと、プロセスは正常に実行できません。



もちろん奇妙ですが、デフォルトのブランチを追加してみてください。それ以外の場合は単一の条件が満たされない可能性があり、エラーが発生するため、デフォルトのブランチが存在することをお勧めします。





図5.デフォルトのブランチ



を使用したサービスプロセス開始しても同じ結果が得られます-プロセスは包括的ゲートウェイでハングしたままです。



次に、あらゆる種類のパラメータを整理し、ドキュメントを読んで、半日続けます。次の試みでは、プロセスは予期せぬ運命のゲートウェイを通り抜けます。インクルーシブゲートウェイを備えた下のブランチは、検索およびデバッグプロセス中に、クライアントの信頼性チェックで上のブランチが削除された状況で機能しました。つまり、包括的ゲートウェイを使用してプロセスが下位ブランチのみに縮退すると、プロセスは終了しました。





図6.縮退プロセス



Parallel Gatewayが何らかの形で包含ゲートウェイに影響を与えることがわかります。これは奇妙で非論理的であり、そうあるべきではありません。



これはどのようにして可能ですか？Parallel and Inclusive Gatewayが再びどのように機能するかについての理論を再読する価値があるでしょう。参加ゲートウェイが全員をまとめてプロセスを続行するには、何が必要ですか？インターネット上では、包括的ゲートウェイ（参加）を収集するすべての人が、「分岐」（分岐）から出たときと同じ数の人々が入るのを待つと書いています。次に、別の質問が突然発生します。このカウンターはどのように機能しますか？

あなたは何者ですか？どのように働きますか？

この問題は、パズルゲームやインテリジェントテレビ番組にふさわしいものです。テレビ番組でのみ、友達に電話をかけることができます。一方、私も助けを求めることができます。ビジネスプロセスアーキテクトをDenisと呼びます。



-デニス、こんにちは！プロセスが先に進む時が来ると、収集の通路がどのように決定するか教えていただけますか？彼らはどこにでも書いている：「どれだけ出てきた-たくさん入るべきだ」しかし、彼はそれをどのように正確に考えていますか？

-とてもシンプル。 Camundaはアクティブな実行の数をカウントします。

- どうもありがとうございます。とりあえず、



何が起こったのか考えてみましょう。 ：これを行うには、もう一度初期判明スキーム、リコール





デフォルトの枝と図7ハンギング・プロセスを



簡単にするために、すべての条件が満たされた場合を考えてみましょう。これらの条件が満たされた後の3つのタスクが実行されたとき、私たちは何を持っていますか？



アクティブな実行はいくつですか？下部のブランチに3つ、上部に1つ、クライアントの信頼性を確認しました。Camundaは、これらが完全に異なる並列ブランチであることを気にしません。重要なのはアクティブな実行の数のみであり、そのうち4つがあり、着信包括ゲートウェイは3つしか受信しませんでした。

訂正

状況を修正するには、収集ゲートウェイがすべての実行を一度に収集する必要があり、その後、理論的にはプロセスが続行されます。のではなく2はゲートウェイへの参加の1を残してみましょう：





図8のプロセスの修正版



悲しいかなは、プロセスを編集した後、私の意見では、あまり目立たないで、外観に始まりました。しかし、当初の計画どおりに機能しました。このクエストは無事終了し、変更をプッシュして家に帰ることができました。

楽しみは始まったばかりです

この記事を書くために腰を下ろして、このケースを説明できるプロセスの例を思いついたとき、私はがっかりしました。プロセスは正常に機能し、デッドロックはありませんでした。



最初は、例のCamundaバージョンがプロジェクトよりも高いと想定していましたが、新しいバージョンではこの問題はすでに修正されています。しかし、カムンダをダウングレードしても何も起こりませんでした。ちなみに、すべての例でバージョン7.8.0が使用されています。これは最新のものとはかけ離れていますが、問題ではありません。この問題もチェックされ、最新バージョン7.13で再現されました。



試行錯誤により、問題は確立されました。元の偽の例には、私が職場で開発していたプロセスとは異なり、逆分岐がありませんでした。



リバースブランチが存在する場合、問題が再現され、一種のデッドロックが発生しますが、リバースブランチがないと、すべてが正常に機能します。



ケースの理解と分析が必要です。これを行うには、カムンダBPMのソースを調べる必要がありました。-問題が包含ゲートウェイとあったので、この要素の振る舞いに責任があるクラスの答えを探すために、論理的に思えたInclusiveGatewayActivityBehavior。プロセスの両方のバージョンでデバッグを数回実行した後、私はそれがどのように機能するかを理解しました。

それが明確でない場合-ソースを参照してください！

退屈なストーリーテリングを行わないようにするために、ソースコードに基づくInclusiveGatewayの作業の説明は概略図になります。対象となるロジックは、executeメソッドに集中しています。この場合、activatesGatewayメソッドが最も価値があります。私の理解では、InclusiveGatewayを通過できるかどうかを確認しています。 executeメソッドは、実行ごと（実行中のブランチごと）に呼び出されます。私たちの場合、そのようなブランチは3つあります。つまり、このメソッドは3回呼び出されます。



activatesGatewayメソッドがどのように機能するかを見てみましょう。よりよく理解するために、すべての実行可能なブランチに名前を付けましょう。





図9.実行を伴うプロセス図



私が理解しているように、メソッドのロジックは次のとおりです。このゲッティに来た処刑の数とこのゲッタウェイに含まれている矢の数が比較されます。このチェックは、すべての包括的ゲートウェイブランチが実行される最も単純な状況の場合に行われ、収集ゲートウェイをチェックするロジックは、入力された実行の数が着信矢印の数と等しくなるまで待機することです。つまり、最も単純なケースでは、コレクションゲートウェイに入るブランチの数だけexecuteメソッドが呼び出され、その後プロセスが続行されます。



今回のケースでは、着信実行の数が1から3に増えるため、このメソッドは3回呼び出されます。最後の呼び出しでは、着信および発信実行の数はそれぞれ3および4になり、falseブランチをたどります。



条件が満たされない場合、残りの実行は包括的ゲートウェイに属しているかどうかがチェックされます。つまり、アクティブな実行が結合包括ゲートウェイに到達する能力がチェックされます。

ここであなたは忍耐強く、息を吐き、読む必要があります。デヌーメントは近いです！

activatesGatewayメソッドのfalseブランチでは、包括的結合の実行でまだ到着していないすべての呼び出しが、この結合に到達する可能性についてチェックされます。少なくとも1つの実行が包括的ゲートウェイにつながる可能性がある場合は、それを考慮に入れて、この結合に到達するまで待機する必要があります。結合につながる可能性のある実行がない場合、メソッドはtrueを返します。



最も興味深い部分は来ています。一見すると、最後の実行（図では-実行1）は包括的ゲートウェイにつながりません。しかし、この検証に携わっているcanReachActivityメソッドの実装を検討する価値はあります。この要素のこの動作の理由は明らかになります。



コードのすべての詳細を破棄すると、このメソッド内でisReachableメソッドが再帰的に呼び出されます。このメソッドは、この実行が収集中のInclusiveGatewayに到達する可能性を段階的にチェックします。逆ブランチはそのような機会を与えるだけであり、悲しいことに、これは考慮されますが、すべての結合の後に戻るので、考慮されません。



その結果、包括的ゲートウェイは次の実行を待っています。したがって、一種のデッドロックが発生します。原則として、規則を破棄すると、古典的なデッドロックが発生します。Parallelでの結合は、包含を含むブランチが実行されるのを待ち、逆に、包含を含むブランチはParallelが実行されるのを待ちます。



以下の図は、パラレルブランチを介してPrallelゲートウェイに参加するようになった実行からの包括的ゲートウェイ参加の可用性をチェックするおおよその方向を示しています。





図10.並列結合から包含結合への可能なパス



この図は、実際に並列ゲートウェイ結合から結合包含ゲートウェイが利用可能であることを示しています。CamundaBPMロジックによると、それはすでに「先に円がある」ことを意味しません。



理由を見つけた後、無意識のうちに問題が発生しました：これはバグですか、それとも機能ですか？私の意見では、これはバグです。現在、カムンダチームにレポートを送信するための情報とケースを収集しています。

問題がローカライズされているのは良いことです。しかし、今はどうですか？

実際、今-結論：

1. 事前警告は前もって行われます。カムンダのこの振る舞いを考慮に入れてプロセスを構築する必要があります。
2. , . parallel join.
3. Inclusive Gateway , , executions .
4. , . , Parallel Gateway .

単純さと明快さを誤解しているように見えることがあります。これは、知識の蓄積と複製を通じてのみ対処できます。悲しいかな、この問題を解決した当時、私は包含的結合のロジックについて深い知識を持っていなかったので、いじくり回さなければなりませんでした。私はこの知識を試行錯誤し、友人に電話し、ソースをデバッグしました。



これらすべてから、使用するツールがどのように機能するかを理解する必要があることは明らかであり、新しい結論には程遠いものです。よく理解すればするほど、そのような問題は少なくなります。



2番目の結論も明らかです。コードだけでなくプロセスも分解する必要があります。



このケースの解析と記事の作成に役立つリンク：

1. Camunda BPMソース
2. 包括的ゲートウェイジョブの説明
3. パラレルゲートウェイジョブの説明