5

我希望我可以在这里更具体，但不幸的是，这可能很难。我基本上希望这是一些“众所周知的”超时或设置问题。

我们有一个网站在工厂的屏幕上运行（JS/html - ASP.net 项目）网站概述。这个屏幕没有键盘，所以它应该永远刷新页面——也许几年（尽管 1 周可能没问题）。（工厂工人使用它来查看进货运输等）

这一切都完美无缺；该站点不断自我更新并获取新的正确数据。然后，有时，早上这个“概览”屏幕没有数据，工作人员必须使用简单的刷新按钮或 F5 手动刷新站点 - 这会修复所有问题。

我尝试了一些尝试自己重现错误的方法，包括：

  1. 切断互联网连接和许多其他使其超时的方法（断点、停止服务等）。
  2. 将 setInterval 的刷新时间设置为 100ms，让站点运行 3-5 分钟。（正常计时器为 1 分钟）
  3. 根据我所做的互联网搜索，setInterval 应该永远运行。
  4. 检查“JavaScript 频率”是否在省电设置中被关闭。

无论; 一旦我再次插入互联网电缆或其他任何东西，该网站就会恢复正确的功能而无需刷新 - 我无法重现该错误。

该网站依赖于后端 WCF 服务和项目集成，但由于工作人员正在通过简单的刷新来解决此问题，我假设这没有崩溃。

编辑：我试图在其中重现错误的浏览器是 IE/win7。我明天会问工厂，但我猜是IE/win？还。

setInterval 实际上真的是无限的还是这里有其他问题？

非常感谢所有帮助。

更新：今天早上我离开网站以调试模式运行后，在网站更新代码的 catch 子句中有一个断点。有 2 分钟。超时错误（可能在夜间忙于服务器清理），然后永远在此行出现空引用错误：

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

我像工人一样刷新了它。我现在认为这可能是会话超时，尽管我们一直在 ping 服务器。当然，我的特定会话超时可能是由断点引起的，使其在第一次超时时永远挂起 - 行为仍然与工厂。我将确保稍后向你们更新最终解决方案。

更新 2：测试正在进行中。

更新 3：工厂是 IE 9，他们的测试机器是 IE 7，我的机器是 IE 9。这个错误是在 IE7 上看到的，但不是我的 IE9 周末运行后。我们尝试在关键的 data_binding 代码期间关闭 ajax 缓存，但它什么也没做。我测试了内存泄漏，如果我每分钟刷新 100 次，就能够产生不错的泄漏。我不认为这是问题所在，并且刷新清理了使用的内存。

我们现在将尝试自动刷新。

4

3 回答 3

3

setInterval()应该永远持续下去。但是，您的脚本/页面可能会泄漏某种资源，最终导致页面脚本或浏览器内部出现错误。

如果是这种情况，您可能最终可以追踪到哪种资源正在泄漏并修复真正的问题，但即使这样做，一些浏览器也有自己的问题，即运行时间很长的进程。

可能值得观察资源使用情况，以查看浏览器内存使用情况是否会随着页面运行时间的增加而增加。但是，由于 F5 修复了它，我建议作为安全措施，您只需每隔几个小时就重新加载一次页面。在大多数现代浏览器中，页面重新加载会释放与先前页面运行相关的所有资源，并从这个角度为您提供一个干净的状态。

只需这样做（每六个小时触发一次）：

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

不仅会给您一个全新的开始，而且还会自动让您的应用程序每隔一段时间检索您可能对应用程序所做的任何服务器端更改，因此如果您发布错误修复，它将在几个小时。

您还可以在页面中使用元刷新标签。

于 2012-11-05T16:53:48.533 回答
1

我猜你被应用程序池的回收所咬。这将重置服务器端应用程序并终止所有会话（至少如果您使用进程内会话，这是默认设置）。此回收可能安排在 03:00 发生，这就是为什么您在常规调试会话中看不到它，但只有当您让它在一夜之间运行时才会看到它。

您可以检查该 Web 服务中是否存在 Session。如果 Session 为 null，则返回一个特殊值，该值会触发页面（您接收的 javascript 代码）来完全重新加载页面，这将创建一个新的 Session。这样您就不必等待计划的页面超时来重新填充页面。

于 2012-11-12T12:44:27.653 回答
0

此处未提及的一种解决方案是将 cookie 设置为具有滑动过期。我们最终做了一些不同的事情，但一个问题是用户身份验证/cookie 超时，然后用户被移动到登录屏幕。

于 2013-06-30T09:10:48.420 回答