非常に奇妙な問題があります。アプリケーションの 1 つが .net リモート処理を使用して継続的にサーバーにクエリを実行しており、100 秒ごとにアプリケーションがクエリを短時間停止してから操作を再開します。アプリケーションは実際には複数のサーバーに同時にクエリを実行し、それらすべてからのデータの受信を同時に停止するため、問題はサーバーではなくクライアントにあります。
3 に答える
3
100 秒は、.Net での Web リクエストのデフォルトのタイムアウトであるため、無料の数値です。
過去に、PSI (Microsoft Project 内の Project Server Interface) がタイムアウトをオーバーライドしなかったため、既定の 100 秒が適用され、その時間より長く通信するとすべてが終了することがわかりました。
すべてのコードにアクセスできますか?また、知らないうちにデフォルトが適用されないように、必要に応じてタイムアウトを設定しましたか?
于 2008-11-17T15:08:22.203 に答える
0
私はこれまでにその動作を見たことがなく、残念ながらそれは十分に漠然としたシナリオです.この掲示板で問題に遭遇した人を見つけるのは難しいと思います. アプリケーションに固有の可能性があります。
問題を絞り込むのに役立つ調査がいくつかあると思います。
- 実際に失速しているのはクライアントかサーバーかを判断します。これを判断できない場合は、パケット フィルタをインストールしてトラフィックを監視し、最後のデータの送信者を確認してください。おそらくバイナリ データを読み取ることはできませんが、少なくとも誰が遅れているかはわかります。
- 遅延の原因がクライアントかサーバーかを特定したら、アプリケーションをデバッグして、ハングが発生するブレークポイントを取得します。これにより、問題の追跡に役立つ十分な詳細が得られるはずです。または、少なくともSOについてより明確な質問をしてください。
于 2008-11-17T15:09:50.937 に答える
0
継続的なクエリを実装するために、アプリケーションはどのようにコーディングされていますか? 連続ループですか？またはThread.Sleepのループ？それともタイマーですか？
最初に、システムがコード内でこの「トリガー」を実行すると予想されるかどうか、またはそうであり、リモーティングサーバーが応答していないかどうかを判断すると便利です...だから、...
デバッグ可能な開発環境でこの問題を再現できない場合は、可能であれば、このループにコードを追加して、「すべき」たびにログ ファイル (またはその他の永続化メカニズム) に書き出すことをお勧めします。リモーティングサーバーにクエリを実行するかどうかを決定するために使用する条件を調べ、問題が再発したときにそれらのログを確認します...
サーバーがリモーティング要求を受信したときに記録するために、リモーティング サーバーで同じことができる場合、これも役立ちます...
...そして、そうです、ちょっと考えただけです(これをどのようにコーディングしたのかわかりません...)が、クライアントで別のスレッドを使用してリモートリクエストを発行し、チャネルが登録されている場合、およびその別のスレッドで登録解除されている場合は、リクエストの競合を解消していることを確認してください。同じマシンで同じポートを同時に2回登録することはできません...（ただし、これがあった場合、クライアントで例外が発生するはずです問題）
于 2008-11-17T15:11:05.210 に答える