40

私はWCFサービスとそれへのサービス参照を持つアプリケーションを持っています。アプリケーションにはループがあり、各反復でこのwcf Webサービスのメソッドを呼び出しています。

問題は、約 9 回の呼び出しの後、停止することです...そしてPause、VS のボタンを押すと、呼び出しを行う回線でスタックしていることがわかります。

しばらく待った後、次のTimeoutExceptionがスローされます。

リクエスト チャネルは、00:00:59.9970000 の後に応答を待っている間にタイムアウトになりました。Request への呼び出しに渡されるタイムアウト値を増やすか、Binding の SendTimeout 値を増やします。この操作に割り当てられた時間は、より長いタイムアウトの一部であった可能性があります。

これについて少し調べたところ、アプリケーションで app.config を編集することを含むいくつかの解決策が見つかりました。その抜粋を以下に示します。

<serviceBehaviors>
    <behavior name="ThrottlingIssue">
        <serviceThrottling maxConcurrentCalls="500" maxConcurrentSessions="500" />
    </behavior>
</serviceBehaviors>

.

<readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" 
 maxArrayLength="2147483647" 
 maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />

次に、デバッグを停止してから数分後に、壊滅的な障害が発生したことを知らせるエラー メッセージが表示されます。

この問題を解決するにはどうすればよいですか? 通常の Web サービスを使用していたときは、この問題は発生しませんでした。

参考までに、全体は次のapp.configとおりです。

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.serviceModel>
        <behaviors>
            <serviceBehaviors>
                <behavior name="ThrottlingIssue">
                    <serviceThrottling maxConcurrentCalls="500" maxConcurrentSessions="500" />
                </behavior>
            </serviceBehaviors>
        </behaviors>
        <bindings>
            <wsHttpBinding>
                <binding name="WSHttpBinding_IDBInteractionGateway" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                    bypassProxyOnLocal="false" transactionFlow="false" hostNameComparisonMode="StrongWildcard"
                    maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
                    allowCookies="false">
                    <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647"
                        maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
                    <reliableSession ordered="true" inactivityTimeout="00:10:00"
                        enabled="false" />
                    <security mode="Message">
                        <transport clientCredentialType="Windows" proxyCredentialType="None"
                            realm="" />
                        <message clientCredentialType="Windows" negotiateServiceCredential="true"
                            algorithmSuite="Default" establishSecurityContext="true" />
                    </security>
                </binding>
            </wsHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:28918/DBInteractionGateway.svc"
                binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IDBInteractionGateway"
                contract="DBInteraction.IDBInteractionGateway" name="WSHttpBinding_IDBInteractionGateway">
                <identity>
                    <dns value="localhost" />
                </identity>
            </endpoint>
        </client>
    </system.serviceModel>
</configuration>

[更新] 解決策:

どうやら、各リクエストの後Close、接続する必要があります...各リクエストの後に接続を閉じていますが、それは魅力のように機能しています。

まだ理解できないのは、app.config で maxConcurrentCalls と maxConcurrentSessions を 500 に設定しているのに、10 しか作れないということです。(上記の app.config に何か問題があるのか​​もしれません)

上記の質問 (現在は破線) に対する答えはapp.config、サービス構成ファイル ( web.config)ではなく client を編集していたためです。

4

6 に答える 6

27

許可される同時接続のデフォルト数は 10 です。
ほとんどの場合、クライアントが接続を閉じていません。

同時呼び出しの数を増やすには、クライアントではなくサービス構成に動作を追加する必要があります。

于 2009-04-11T02:00:08.853 に答える
3

clientservice.close（）を呼び出すと、問題が解決します。

于 2011-08-02T15:43:31.217 に答える
1

今週、この問題に遭遇しましたが、何が起こっているのかよくわかりませんでした。実際に、サービスへの呼び出しをDispose()サービス クライアントに変更しましたが、効果がないように見えました。どうやら、別のサービスコールがどこかに潜んでいたようです。

注目すべき興味深い点は、これが問題ではないと判断した理由です。この制限は、Web サービスへのソケット接続の実際の数とは関係ありません。maxConcurrentSessions制限に達しても、実際のソケット接続は 1 つだけです。これを でチェックしてnetstatいたのですが、間違った結論に至りました。したがって、セッションとソケットを混同しないでください。

すべての WCF サービスに対して定義されたインターフェイスがあるため、このパターンをコードに適用することを計画しています。

IMyService service = new MyServiceClient();
using (service as IDisposable)
{
    service.MyServiceMethod();
}

また興味深いのは、サービス (および Web サイト) が IIS でホストされていた場合、問題が発生しなかったことです。構成は (ほぼ) 同じですが、そのマシンでこの動作を再現できませんでした。それは良いことだと思います:)

@ John Saunders ( の変数代入についてusing):

私は通常、変数の割り当てをusingステートメントに入れます。しかし、生成された IMyService は暗黙的に に変換できませんIDisposable。本当にそこに割り当てが必要な場合は、代替案は次のようになると思います。

IService service;
using ((service = new ServiceClient()) as IDisposable)
{
}

ただし、変数のスコープが間違っているという問題はまだ残っています。への参照IService serviceは使用できませんが、スコープ内にあります。したがって、これはその点でより良いでしょう：

using (IDisposable serviceDisposable = new ServiceClient())
{
     IService service = (IService)serviceDisposable;
}

ただし、追加の変数名を導入する必要があります。*まあ*

于 2009-08-05T18:29:50.337 に答える
1

これは、Web サービス参照とアプリケーションの間のインターフェースとしてシングルトン クラスを作成することで解決できます。次に、サービス参照のインスタンスを 1 つだけ作成します。

class ServiceInterface
{
     private static ServiceInterface  _instance;
     private ServiceClient _service = new ServiceClient ;
     private ServiceInterface()
     {
       //Prevent accessing default constructor
     }

     public static ServiceInterface GetInstance()
     {

     if(_instance == null)

     {

      _instance = new ServiceInterface();

    }

        return _instance;



 }


   // You can add your functions to access web service here

    Public int PerformTask()
    {
         return _service.PerformTask();
    }
}
于 2010-06-25T15:39:02.827 に答える
0

どちらでも解決されなかった非常によく似た問題に髪の毛を引っ張った後、Close()またはデフォルトで2であるをDispose()増やすことで、私の一日を作った簡単な解決策を追加したいと思います.ServicePointManager.DefaultConnectionLimit

「DefaultConnectionLimit プロパティは、ServicePoint オブジェクトの作成時に ServicePointManager オブジェクトが ConnectionLimit プロパティに割り当てるデフォルトの最大同時接続数を設定します。」

私の場合、アプリケーションはリモート サービスに 2 回正常に接続しましたが、3 回目は単にサービスに接続しようとしませんでした。代わりに、上記の質問と同じエラー メッセージでタイムアウトになるまでしばらく待機しました。増やすDefaultConnectionLimitことで解決しました。フラストレーションに加えて、この動作はいくぶんランダムでした。10 のうちの 1 つのケースでは、Web サービスが複数回 (>2 回) 正常に呼び出されました。

解決策は、 wcf-timeout-exception-detailed-investigationとwcf-service-throttlingの 2 つのスレッドから始まり、さらに議論されます。私の問題を解決しました。

于 2011-08-18T20:16:21.547 に答える
0

トレースを構成してループを実行できますか? チャネルに障害が発生し、クライアントがタイムアウトになっている可能性があります。

于 2009-04-11T01:49:52.013 に答える