5

ここでもっと具体的にできたらいいのですが、残念ながらこれは難しいかもしれません。基本的に、これが「よく知られた」タイムアウトまたはセットアップの問題であることを願っています。

工場の画面で (JS/html - ASP.net プロジェクト) Web サイトの概要を実行している Web サイトがあります。この画面にはキーボードがないため、ページを永久に更新し続ける必要があります。おそらく何年も (1 週間で十分かもしれませんが)。（工場の作業員が搬入搬出などを確認するために使用）

これはすべて完全に機能します。サイトは継続的に更新され、新しい正しいデータを取得します。その後、朝になると、この「概要」画面にデータが表示されず、ワーカーは単純な更新ボタンまたは F5 キーを使用してサイトを手動で更新する必要があり、これですべてが修正されます。

エラーを自分で再現しようとして、次のようないくつかのことを試しました。

  1. インターネット接続を切断し、タイムアウトにする他の多くの方法 (ブレークポイント、サービスの停止など)。
  2. setInterval の更新時間を 100 ミリ秒に設定し、サイトを 3 ～ 5 分間実行します。（通常のタイマーは1分です）
  3. setInterval は、私が行ったインターネット検索によると、永久に実行する必要があります。
  4. 省電力設定で「JavaScript頻度」を下げていないことを確認しました。

何があっても; インターネットケーブルなどを再度接続するとすぐに、サイトは更新なしで正しい機能を再開します-エラーを再現できません.

Web サイトはバックエンドの WCF サービスとプロジェクトの統合に依存していますが、ワーカーが単純な更新でこれを修正しているため、これはクラッシュしていないと思います。

編集: エラーを再現しようとしたブラウザは IE/win7 でした。明日ファクトリーについて聞いてみますが、IE/winでしょうか？また。

実際に setInterval は本当に無限ですか、それとも他に何か問題がありますか?

すべての助けに感謝します。

更新: サイト更新コードの catch 句にブレークポイントを設定してデバッグ モードで実行している Web サイトを離れた後、今朝来ました。2分ありました。タイムアウト エラー (夜間にサーバーのクリーンアップがビジー状態になる可能性があります) が発生し、その後、次の行で null 参照エラーが発生します。

var showHistory = (bool)Session.Contents["ShowHistory"];

労働者のようなリフレッシュで修正しました。サーバーにpingを実行し続けていますが、セッションタイムアウトである可能性があると考えています.工場。後で最終的な解決策をお知らせします。

更新 2: テストは進行中です。

更新 3: 工場は IE 9、テスト マシンは IE 7、私のマシンは IE 9 です。エラーは IE7 で見られましたが、週末の実行後に IE9 では見られませんでした。重要な data_binding コードで ajax キャッシュをオフにしようとしましたが、何もしませんでした。メモリ リークのテストを行ったところ、1 分間に 100 回更新すると、まともなリークが発生することがわかりました。それが問題だとは思いませんが、リフレッシュすると使用されたメモリがクリーンアップされました。

ここで、自動更新を試します。

4

3 に答える 3

3

setInterval()永遠に続くはずです。ただし、スクリプト/ページが何らかのリソースをリークしていて、最終的にページスクリプトまたはブラウザの内部でエラーが発生する可能性があります。

この場合、最終的にはどのような種類のリソースがリークしているかを追跡し、実際の問題を修正できますが、それを行っている場合でも、一部のブラウザーには非常に長時間実行されるプロセスに関する独自の問題があります。

ページの実行時間が長くなるほどブラウザのメモリ使用量が増えるかどうかを確認するために、リソースの使用量を監視することはおそらく価値があります。ただし、F5で修正されるため、安全対策として、ページを数時間ごとにリロードすることをお勧めします。最近のほとんどのブラウザでは、ページのリロードが行われ、前のページの実行に関連するすべてのリソースが解放され、その観点からきれいな状態になります。

これを行うだけです（6時間ごとにトリガーされます）：

setTimeout(function() {
    window.location.reload(true);
}, 6 * 1000 * 60 * 60);

クリーンなスタートを切るだけでなく、アプリにサーバー側で加えた変更を時々自動的に取得するため、バグ修正を発行すると、数時間以内に自動的にデプロイされます。時間。

ページでメタリフレッシュタグを使用することもできます。

于 2012-11-05T16:53:48.533 に答える
1

アプリケーションプールのリサイクルに悩まされていると思います。これにより、サーバー側のアプリケーションがリセットされ、すべてのセッションが強制終了されます（少なくとも、デフォルトであるin-procセッションを使用する場合）。このリサイクルは03:00に実行されるようにスケジュールされている可能性があるため、通常のデバッグセッションでは表示されませんが、夜間に実行したままにしておく場合にのみ表示されます。

そのWebサービス内のセッションの存在を確認できます。セッションがnullの場合は、ページ（受信側のJavaScriptコード）がページの完全なリロードを実行するようにトリガーする特別な値を返します。これにより、新しいセッションが作成されます。このように、ページを補充するためにスケジュールされたページタイムアウトを待つ必要はありません。

于 2012-11-12T12:44:27.653 に答える
0

ここで言及されていない解決策の 1 つは、Cookie の有効期限がスライドするように設定することです。最終的にいくつかの異なることを行いましたが、1 つの問題はユーザー認証/Cookie のタイムアウトであり、ユーザーはログイン画面に移動しました。

于 2013-06-30T09:10:48.420 に答える