3

信頼できるリクエスト返信では、返信が承認され信頼できるものであることを理解しています。なんらかの理由で、応答メッセージが 8 回すべての試行 (デフォルトの再試行回数は 8 回) で継続的に失敗した場合、チャネルに障害が発生します。

サーバー側のサービス メソッドでは、応答が失敗した場合に対処する必要がありますが、サービス メソッドが WCF コンテキストを認識していないため、これを達成する方法がわかりません。

    /// <summary>
    /// This is my service method, and does the reply in reliable request reply
    /// </summary>
    /// <returns></returns>
    public IModelJob GetNextJob()
    {
        //dequeue the next item if there is any
        var modelJob = _priorityQueue.Dequeue();

        //if all attempts to reply fail (or at least fail to be acknowledged) then when and how do I get a chance to requeue this job?
        return modelJob;

    }

ClientBase から独自のプロキシを実装できるため、クライアントであり、プロキシ自体でサービス メソッドを呼び出すと、障害を処理するのがはるかに簡単になるようです。

http://msdn.microsoft.com/en-us/library/aa480191.aspxを読み、検索しましたが、具体的なものは何も見つかりません。

4

1 に答える 1

0

最終的にサポートする事業運営の観点から考えてください。たとえば、サービスが定期的に 30 分間隔でクライアントから一連のメッセージを受信することを期待している場合、メッセージが 120 分間表示されない場合、サービスが管理者。これは、サービスを駆動するビジネス ロジックに実装されます。

メッセージを受信して​​いないときに例外をスローできないことは、WCF の欠点ではありません。

Reliable Messaging は、HTTP アプリケーションがまったく認識せずに TCP 再送信が行われるのと同じように、アプリケーションの下の層で機能することに注意してください。TCP レベルで 1 回または複数回の再送信が必要であるという事実は、受信者にとっては問題ではなく、プロトコル スタックに例外がスローされることもありません。データを送信できなかったことを最終的に検出し、それに対して何かを行うのは、データの送信者次第です。または、私が示した例では、サービスの背後にあるビジネス ロジックがビジネス レベルで要件を実装します。

WS-ReliableMessaging のいくつかの欠点について書いたブログ投稿に興味があるかもしれません。

于 2013-11-24T03:12:29.230 に答える