問題タブ [timeoutexception]

SoapClient を使用して WebServices を呼び出すときに生成される TimeoutException をどのように処理しますか?

Web サービスの呼び出し時に生成された例外をキャッチするために処理するイベントはないようです。

スローされた例外、特に TimeoutException をキャッチすることは可能ですか??

この質問を Silverlight.net フォーラムにも投稿しました: http://silverlight.net/forums/p/46029/124010.aspx

ログ ファイルの分析 サービス呼び出しの約 1% が、Silverlight クライアント側で TimeoutException で終了していることに気付きました。サービス (wcf) は非常に単純で、長い計算を実行しません。ログによると、サービスへのすべての呼び出しは常に 1 秒未満で処理されるため (クライアントで TimeoutException が発生した場合でも!)、サーバーのタイムアウトではありません。

では、何が問題なのですか？構成またはネットワークの問題でしょうか? どうすれば回避できますか？この問題のローカライズに役立つ追加のログ情報は何ですか?

私が考えた唯一の回避策は、タイムアウト後にサービス呼び出しを再試行することです。

この問題について何か助けていただければ幸いです。

更新:起動時に、アプリケーションは 17 のサービス コールを実行し、そのうち 12 を同時に実行します (失敗の原因でしょうか?)。

更新: WCF ログには、この問題に関する有用な情報が含まれていません。一部のサービスコールがサーバー側に届かないようです。

IIS7で実行されているWCFサービス（* .svc）と、サービスをクエリしているさまざまなクライアントを持つアプリケーションがあります。サーバーはWin2008Serverを実行しています。クライアントは、Windows2008ServerまたはWindows2003サーバーのいずれかを実行しています。次の例外が発生しています。これは、実際には、多数の潜在的なWCFの問題に関連している可能性があります。

タイムアウトを30分に増やしましたが、エラーは引き続き発生しました。これは、データの量がアップロードまたはダウンロードに30分かかることは決してないため、何か他のものが機能していることを示しています。

エラーが発生したり消えたりします。現時点では、より頻繁です。3つのクライアントを同時に実行している場合でも100のクライアントを実行している場合でも、問題はないようですが、それでもたまに発生します。ほとんどの場合、タイムアウトはありませんが、それでも1時間に数回発生します。エラーは、呼び出されたメソッドのいずれかから発生します。これらのメソッドの1つにはパラメーターがなく、少しのデータを返します。もう1つは、パラメータとして大量のデータを取り込みますが、非同期で実行されます。エラーは常にクライアントから発生し、スタックトレース内のサーバー上のコードを参照することはありません。それは常に次で終わります：

サーバー上：次のバインディング設定を試しました（現在は持っています）。

影響はないようです。

私は次のスロットル設定を試しました（そして現在持っています）：

影響はないようです。

現在、WCFサービスに対して次の設定があります。

ConcurrencyMode.Multipleしばらく走りましたが、それでもエラーが発生しました。

IISを再起動し、基盤となるSQL Serverを再起動し、マシンを再起動してみました。これらすべてが影響を与えるわけではないようです。

Windowsファイアウォールを無効にしてみました。影響はないようです。

クライアントには、次の設定があります。

クライアントが接続を閉じます。

より多くの発信接続を許可するようにレジストリ設定を変更しました。

最近、SvcTraceViewer.exeを試しました。クライアント側でなんとか1つの例外をキャッチできました。所要時間は1分です。サーバー側のトレースを見ると、サーバーがこの例外を認識していないことがわかります。私が見ることができる最大の持続時間は10秒です。

exec sp_whoサーバーで使用しているアクティブなデータベース接続を確認しました。私はほんの少ししか持っていません（2-3）。TCPviewを使用して1つのクライアントからのTCP接続を調べました。それは通常2-3前後で、私は5または6まで見ました。

簡単に言えば、私は困惑しています。私は見つけたすべてのことを試しましたが、WCFの専門家が見ることができる非常に単純なものが欠けているに違いありません。サーバーが実際にメッセージを受信する前に、何かが低レベル（TCP）でクライアントをブロックしている、および/または何かがサーバーレベルでメッセージをキューに入れて、決して処理させていないのは私の直感です。

私が見なければならないパフォーマンスカウンターがあれば、私に知らせてください。（これらのカウンターのいくつかは解読が難しいので、どの値が悪いかを示してください）。また、WCFメッセージサイズをログに記録するにはどうすればよいですか？最後に、クライアントとサーバー間で（アプリケーションとは関係なく）確立できる接続の数をテストできるツールはありますか？

御時間ありがとうございます！

6月20日に追加された追加情報：

私のWCFアプリケーションは次のようなことをします。

WireSharkを使用して、エラーが発生したときに、5回のTCP再送信と、その後のTCPリセットがあることを確認しました。私の推測では、RSTはWCFが接続を切断することから来ています。私が受け取る例外レポートは、ステップ3のタイムアウトからのものです。

これは、tcpストリーム「tcp.streameq192」を見て発見しました。次に、フィルターを「tcp.streameq192およびhttpおよびhttp.request.methodeqPOST」に拡張し、このストリーム中に6つのPOSTを確認しました。これは奇妙に思えたので、tcp.stream eq 100などの別のストリームで確認しました。3つのPOSTがありましたが、3回の呼び出しを行っているため、もう少し正常に見えます。ただし、すべてのWCF呼び出しの後に接続を閉じるので、ストリームごとに1つの呼び出しを期待していました（ただし、TCPについてはよくわかりません）。

もう少し調べて、httpパケットの負荷をディスクにダンプして、これらの6つがどこで何を呼び出すかを調べました。

私の推測では、2つの同時クライアントが同じ接続を使用しているため、重複が見られました。ただし、理解できない問題がまだいくつかあります。

a）パケットが破損しているのはなぜですか？ランダムネットワークのまぐれ-多分？次のサンプルコードを使用してロードをgzip圧縮します。http：//msdn.microsoft.com/en-us/library/ms751458.aspx-同時に使用すると、コードにバグが発生することがありますか？gzipライブラリなしでテストする必要があります。

b）破損した操作がタイムアウトした後、ステップ1とステップ2が実行されるのはなぜですか？これらの操作は行われるべきではなかったように私には思えます。TCPの理解に欠陥があるため、正しいストリームを見ていません。同時に発生する他のストリームがあります。他のストリームを調査する必要があります。ストリーム190〜194をひと目見ると、Step3 POSTに適切なペイロードデータ（破損していない）があることがわかります。gzipライブラリをもう一度見るように私をプッシュします。

SQL Management Studio で CommandTimeout を変更するにはどうすればよいですか?

この 1 つのストアド プロシージャには問題があります。このストアド プロシージャは、アプリケーション全体で 99% の時間動作しますが、アプリケーションの特定の部分から呼び出されるとタイムアウトになります。

テーブルには 3 つの列しかなく、約 300 のレコードが含まれています。ストアド プロシージャは 1 つのレコードのみを返し、次のようになります。

"Select * from Table Where Column = @parameter"

sp が管理スタジオで実行されると、00 秒かかります。

ストアド プロシージャはアプリケーションで頻繁に使用されますが、プログラムの特定の部分でのみタイムアウトするようです。このような単純な sp がタイムアウトする理由は考えられません。何か案は？

これは vb.net デスクトップ アプリケーションであり、SQL Server 2005 を使用しています。

私はこのようなことをする必要があるコードを持っています

それぞれにいくつかのメソッド（execute（）など）を持つクラスのリストがあります。各クラスでそのメソッドを呼び出す必要があり、呼び出しごとに固定のtimeOutがあります。現在、クラスのexecuteメソッドの1つが正しく記述されておらず、jvmが終了しないためにタイムアウトが発生します。私はこのようにクラスを運営しています。

コードの実行が完了した後、jvmが終了しないのはなぜですか？

次の出力が得られます

2番目のクラスの実行がタイムアウトし、その後、3番目のクラスの実行もタイムアウトします。3番目のクラスの実行がタイムアウトするのはなぜですか？

実行が完了した後、jvmは終了しません。理由は何ですか？また、TestClass3実行がタイムアウトするのはなぜですか？

3つのWCFサービスを備えたプログラムがあり、それらをローカルで実行すると（つまり、サーバーとクライアントはすべてローカルホスト上にあります）、すべてが機能します。ただし、ネットワークを介してそれらをテストすると、2つのサービスでTimoutExceptionが発生しますが、他のサービスでは発生しません。テストに関係するすべてのマシンでファイアウォールを無効にしました。サーバーにpingを実行することも、クライアントからwsdl「サービスを作成しました」Webページにアクセスすることもできます。

動作するサービスはストリーミングでBasicHttpBindingを使用し、動作しない2つはWSDualHttpBindingを使用します。WSDualHttpBindingを使用するサービスには、両方ともCallbackContractsがあります。この質問があいまいであることをお詫びしますが、どのコードを含めるべきか、またはこれに対する解決策をどこから探し始めるのかさえよくわかりません。

動作しないバインディング：

例外スタックトレース：

WCF では、要求応答操作のタイムアウトにより、クライアント側のチャネルに障害が発生しますか?

サーバーが応答を送信するときにタイムアウトした場合、チャネルはサーバー側で障害が発生していますか?

C++0x では、指定された時間に達するまでミューテックスをロックし、ミューテックスがロックされているかどうかを示すブール値を返すことができます。

状況によっては、タイムアウトのためにロックが失敗するという例外的な状況を考えます。この場合、例外をより適切に設定する必要があります。

違いを生むために、関数 lock_until を使用して、ロックする前に時間に達したときにタイムアウト例外を取得できます。

一部のコンテキストでは、lock_until の方が適切であると思いますか? はいの場合、どのものですか？いいえの場合、なぜ try_lock_until が常により良い選択になるのでしょうか?

Rails 2.3.5を使用しており、一見ランダムなTimeout :: Error：実行期限切れエラーが発生しています。Hoptoadによって報告されたエラーは、特定のコントローラーで一貫して発生するわけではなく、ユーザーセッションからアカウント設定、一部のコア機能コントローラーに至るまで、あらゆる場所に表示されます。

リクエストの大部分はタイムアウトしませんが、懸念を引き起こすのに十分です。

これは正常ですか？もしそうなら、発生を減らすために注意すべきことは何ですか？そうでない場合は、誰かがこれに遭遇し、このようなエラーを引き起こす可能性のあるいくつかの一般的な問題は何ですか？