しばらくの間、問題なくテストされているいくつかの WCF サービスがあります。Windows プロセス アクティベーション サービス (WAS) を使用して IIS でそれらをホストします。クライアントが接続すると、サービスが起動し、満足しています。
さて、私は偏執狂的ですが、これを出荷する前に、サービスが特定の種類の障害を処理する方法に関連するさまざまなエッジ ケースをテストしたいと思いました。実験の 1 つは、特定のサービスの ServiceHost 自体の作成中に失敗しました。
一部の初期化作業を行い、完全に構成されたサービス ホストを返すカスタム ServiceHostFactory (ServiceHostFactoryBase から派生) があります。初期化中に CreateServiceHost が ServiceActivationException をスローする構成エラーをシミュレートしています。また、例外をログに記録します。
[余談ですが、クライアントがこの例外を確認すると、サービスへのアクセスを停止します (初回のアクティブ化に失敗した場合、人間が関与する必要があるという前提で)。これは、一時的なネットワーク状態を想定して、クライアントが定期的に試行し続ける EndpointNotFoundException などとは異なります。]
私たちが見ているのは、クライアントが (1 回) サービスへのチャネルを開こうとしているということです。ServiceHostFactory は、サービスをアクティブ化するために数秒間にわたって何度も試みているように見えますが、それぞれの試みは予期された例外メッセージで失敗し、アプリケーション プールは単純にロックされているように見えます。そのアプリ プール内で実行されている (正常にアクティブ化された) 他のサービスへの呼び出しは永久にハングします。
それは奇妙に思えます。失敗したサービスをアクティブ化しようとして数回失敗した後、失敗したサービスがアプリ プールから起動されることは気にしませんが、他のサービスを強制終了するのは間違っているようです。アプリ プールはリサイクルも停止もしないことに注意してください。サービス操作への要求に応答せずにそのまま待機します。
あるサービスのアクティブ化に失敗すると、そのサービスは「オフライン」になるが、アプリ プール内の他のサービスは引き続き要求を処理できるようにする必要があることを WCF に伝えるために、何か他にすべきことはありますか? それとも、WAS でもっと基本的なことが抜けているのでしょうか?