タイトルがややこしいので、詳しく説明します。
バックエンドサーバーの一部として使用する以外に、スレッドセーフではない dll があります。スレッドの問題によりクラッシュするため、サーバーで直接使用することはできません。そこで、それぞれが 1 つのアクターをホストする N ノードの akka.net クラスターを作成しました。元々その不良な dll に対して行われていたすべての API 呼び出しは、ラウンド ロビン グループを介してこれらのノードへのメッセージを通じてルーティングされるようになりました。各ノードにはシングル スレッド アクターが 1 つしかないため、安全にアクセスできますが、N 個のアクターを実行しているため、ある種の並列性が得られます。
本番環境ではauto-down = false、ハートビートなどのデフォルトのタイミングで構成されたものがあります。これは完全に機能します。必要に応じて新しいノードを起動したり、グループに追加したり、削除したりできCluster.Leaveます。これも満足です。
私の問題はデバッグにあります。私たちの開発環境では、20 個のノードからなるクラスターを維持し、それぞれが上記のようにこの dll をラップする単一のアクターを公開しています。また、シード ノードとして機能し、他に何もしない一連のノードもあります。
アプリケーションが実行されると、クラスターに参加します。これにより、ラウンドロビン ルーターを介して、クラスター内で保持しているノードに要求を送信できます。アプリの開発、テスト、デバッグを行っているときに、使用するものを構成するとauto-down = false
、テストの実行がクラッシュしたり、適切なクラスターを経由せずにロジックを残してアプリケーションを停止したりするたびに、問題が発生します。デバッガーの停止ボタンでアプリを終了するときなど。
自動停止がないと、クラスターのメンバーが欠落したままになり、リーダーがクラスターへの追加を許可しなくなります。これは、次回アプリを実行してデバッグするときに、クラスターに参加できず、立ち往生していることを意味します。
デバッグを機能させるには、オートダウンを設定する必要があるようです。設定されている場合、アプリをクラッシュさせると、ノードは 5 秒後にクラスターから削除されます。次にアプリを起動すると、クラスターは正常な状態に戻り、問題なく参加できます。
これに関する問題は、アプリケーションをデバッグしてしばらく一時停止すると、ほとんどすぐに到達不能と見なされ、5 秒後にクラスターからスローされることです。基本的に、これらの設定ではデバッグできません。
だから、私は設定しましたfailure-detector.acceptable-heartbeat-pause = 600sデバッグ中にアプリを一時停止する時間を増やすために。10 分でシャットダウンしますが、それほど長くデバッガーに座っていることはあまりないので、許容できるトレードオフです。もちろん、これに関する問題は、アプリをクラッシュさせるか、デバッガーで停止すると、クラスターは次の 10 分間存在すると見なすことです。誰もこれらのノードと直接通信しようとしないため、理論的には大きな問題ではありませんが、実行したばかりのテスト自体がロール リーダーとして選出されるケースに何度も遭遇します。そのため、役割のリーダーは死んでいますが、クラスターはまだそれを認識していません。これにより、10分が経過するまで、クラスターに新しいものを参加させることができないようです。うまくクラスタを離れようとすると、デッド ノードが終了状態でスタックし、10 分間削除されません。また、削除の通知が常に届くとは限りません。
「私をリーダーにしないで」と言う方法はないようです。クラスターにロールを設定せずにアプリを実行すると、それ自体がクラスター リーダーとして選出されることが多く、ロール リーダーが死んでいるが不明な場合と同じ問題を引き起こしますが、より大きなレベルで発生します。
だから、これを回避する方法は本当にわかりませんが、誰かがこれをやってのけるためのトリックを持っているかもしれません. クラスター メンバーがクラスターから追い出されることなくデバッグできるようにしたいのですが、リーダー ノードが存在しないのに存在するとクラスターに認識させたくありません。
何か案は？