【问题标题】:Chrome not handling jquery ajax queryChrome 不处理 jquery ajax 查询
【发布时间】:2012-07-02 14:49:25
【问题描述】:

我在 jquery 中有以下查询。它正在读取使用 Nginx 的长轮询模块设置的 Nginx 订阅/发布对的“发布”地址。

function requestNextBroadcast() {
        // never stops - every reply triggers next. 
        // and silent errors restart via long timeout. 
        getxhr = $.ajax({
            url: "/activity",
            // dataType: 'json',
            data: "id="+channel,
            timeout: 46000, // must be longer than max heartbeat to only trigger after silent error. 
            error: function(jqXHR, textStatus, errorThrown) {
                alert("Background failed "+textStatus);  // should never happen 
                getxhr.abort(); 
                requestNextBroadcast();  // try again
            },
            success: function(reply, textStatus, jqXHR) {
                handleRequest(reply);   // this is the normal result. 
                requestNextBroadcast(); 
            }
        });
    }

代码是聊天室的一部分。发送的每条消息都会以空 rply(带有 200/OK)回复进行回复,但会发布数据。这是在数据返回时读取订阅地址的代码。

使用超时功能,聊天室中的所有人每 30 到 40 秒发送一条简单消息,即使他们没有输入任何内容,因此该代码有大量数据可供读取 - 至少 2 条甚至更多消息每 40 秒。

代码在 EI 和 Firefox 中是 100% 坚如磐石的。但是大约 5 次阅读中的一篇在 Chrome 中失败了。

当 Chrome 失败时,超时时间为 46 秒。

日志显示在任何时候有一个 /activity 网络请求未完成。

我已经在这段代码上爬了 3 天,尝试了各种想法。每次 IE 和 Firefox 工作正常而 Chrome 失败。

我看到的一个建议是让调用同步 - 但这显然是不可能的,因为它会锁定用户界面太久。

编辑 - 我有一个部分解决方案:代码现在是这样的

function requestNextBroadcast() {
    // never stops - every reply triggers next. 
    // and silent errors restart via long timeout. 
    getxhr = jQuery.ajax({
        url: "/activity",
        // dataType: 'json',
        data: "id="+channel,
        timeout: <?php echo $delay; ?>,
        error: function(jqXHR, textStatus, errorThrown) {
            window.status="GET error "+textStatus;
            setTimeout(requestNextBroadcast,20);  // try again
        },
        success: function(reply, textStatus, jqXHR) {
            handleRequest(reply);   // this is the normal result. 
            setTimeout(requestNextBroadcast,20); 
        }
    });
}

结果有时回复会延迟到 $delay (15000) 发生,然后排队的消息到达太快而无法跟进。使用这种新安排,我无法让它丢弃消息(仅在关闭 netwrok optomisation 的情况下进行测试)。

我非常怀疑延迟是由于网络问题 - 所有机器都是我的一台真实机器中的虚拟机,并且我的本地 LAN 没有其他用户。

编辑 2(英国夏令时星期五 2:30) - 将代码更改为使用承诺 - 动作的 POST 开始显示相同的症状,但接收方开始正常工作! (??????!!!???)。 这是 POST 例程 - 它正在处理一系列请求,以确保一次只有一个未完成。

function issuePostNow() {
    // reset heartbeat to dropout to send setTyping(false) in 30 to 40 seconds. 
    clearTimeout(dropoutat);
    dropoutat = setTimeout(function() {sendTyping(false);},  
                           30000 + 10000*Math.random()); 
    // and do send 
    var url = "handlechat.php?";
    if (postQueue.length > 0) {
        postData = postQueue[0];
        var postxhr = jQuery.ajax({ 
            type: 'POST',
            url: url,
            data: postData,
            timeout: 5000
        })
        postxhr.done(function(txt){
            postQueue.shift();  // remove this task
            if ((txt != null) && (txt.length > 0)) {
                alert("Error: unexpected post reply of: "+txt)
            }
            issuePostNow();
        });
        postxhr.fail(function(){
            alert(window.status="POST error "+postxhr.statusText);
            issuePostNow();
        });
    }
}

关于 8 中的一项操作,对 handlechat.php 的调用将超时并出现警报。一旦警报被确定,所有排队的消息都会到达。

而且我还注意到,handlechat 调用在写入其他人会看到的消息之前就停止了。我想知道它是否可能是 php 对会话数据的一些奇怪处理。我知道它会小心地将调用排队,以免会话数据损坏,所以我一直小心使用不同的浏览器或不同的机器。只有 2 个 php 工作线程,但是 php 不用于处理 /activity 或提供静态内容。

我也认为这可能是 nginx worker 或 php 处理器的短缺,所以我提出了这些。现在让事情失败变得更加困难——但仍然有可能。我的猜测是 /activity 调用现在失败了 30 次,并且根本不会丢弃消息。

感谢大家的意见。


调查结果摘要。

1) 这是 Chrome 中的一个错误,已经在代码中出现了一段时间。
2) 如果运气好,该错误可以显示为未发送的 POST,并且当超时时,它会使 Chrome 处于重复 POST 将成功的状态。
3) 用于存储 $.ajax() 返回的变量可以是本地的或全局的。新的(承诺)和旧的格式调用都触发了这个错误。
4)我还没有找到解决这个问题的方法或方法。

伊恩

【问题讨论】:

  • 如果您怀疑这是 Chrome 的问题,它可能会帮助其他人了解您使用的版本。 jQuery 版本也是。
  • 客户端Chrome 20.0.1132.47 m jquery 1.7.2 O/S 64位windows,服务端Ubuntu 11:04。
  • 我一直在 Safari (5.1.7) 中对此进行测试,发现它有效。所以这不是 Webkit 问题。还尝试在 Chrome for Linux 的 20.0.1132.47 版本中出现问题。
  • 我已将超时更改为 10 秒并删除了警报,因此如果读取未能找到任何数据,则会超时并重新发出。现在日志显示很多超时读取,但所有数据都通过了!看来,在 tmeout/abort 之后在 Chrome 中的清除设置很好,而在成功后重用它有时会以某种方式失败。它不是一个漂亮的解决方案,也不是高性能的 - 但也许是必要的。
  • 说得太早了。它仍然会丢失消息。这是值得注意的,当发送后不久没有完成读取。我试图检测丢失的回复,并中止/重新发出读取。造成了多大的混乱!多次读取未完成,并反复发送失败 - 然后突然间,在大量背景读取中一切都清除了,留下两个未完成。看来 .abort() 并不总是中止消息。 :(

标签: javascript jquery google-chrome


【解决方案1】:

我在使用 Chrome 时遇到了非常相似的问题。我正在进行 Ajax 调用,以便每秒从服务器获取时间。显然,Ajax 调用必须是异步的,因为如果不是,它将在超时时冻结接口。但是一旦 Ajax 调用中的一个失败,随后的每个调用也是如此。我首先尝试将超时设置为 100 毫秒,这在 IE 和 FF 中运行良好,但在 Chrome 中却不行。我最好的解决方案是将类型设置为 POST 并为我解决了 chrome 的错误:

   setInterval(function(){ 
      $.ajax({
         url: 'getTime.php',
         type: 'POST',
         async: true,
         timeout: 100,
         success: function() { console.log("success"); },
         error: function() { console.log("error"); }
       });
   }, 1000);

更新: 我相信这里实际的潜在问题是 Chrome 的缓存方式。似乎当一个请求失败时,该失败会被缓存,因此永远不会发出后续请求,因为 Chrome 会在启动后续请求之前获取缓存的失败。如果您转到 Chrome 的开发人员工具并转到“网络”选项卡并检查正在发出的每个请求,就可以看到这一点。在失败之前,每秒钟都会向 getTime.php 发出 ajax 请求,但在 1 次失败之后,永远不会发起后续请求。因此,以下解决方案对我有用:

   setInterval(function(){ 
      $.ajax({
         url: 'getTime.php',
         cache: false,
         async: true,
         timeout: 100,
         success: function() { console.log("success"); },
         error: function() { console.log("error"); }
       });
   }, 1000);

这里的变化是我禁用了对这个 Ajax 查询的缓存,但是为了这样做,类型选项必须是 GET 或 HEAD,这就是我删除 'type: 'POST'' 的原因(GET 是默认值)。

【讨论】:

    【解决方案2】:

    尝试将您的轮询功能移动到 webworker 中,以防止在 chrome 中冻结。 否则,您可以尝试使用 jquery 对象的 ajax .done() 。那个总是在 chrome 中为我工作。

    【讨论】:

    • 谢谢迈克尔。 Webworker 是不切实际的——我必须支持 IE——而且没有必要,因为我所做的任何事情都需要足够长的时间才能注意到。问题不是没有调用success(),而是即使有已知数据要读取,读取也没有完成。简而言之,可能会在数据可用后 8 秒内调用成功。不过我会检查 done(),然后告诉你。
    • 我在想的是你做一个浏览器检查,如果它的 chrome,激活进行同步调用的 webworker。这样你可能会修复 chrome,因为只有 chrome 会出现问题。一定要喜欢浏览器的差异。我希望 .done 解决方案对您有用。这是最简单的实施方式。
    【解决方案3】:

    我觉得 getxhr 应该以“var”为前缀。您不想每次都需要一个完全独立的新请求,而不是在成功/失败处理过程中覆盖旧请求吗?可以解释为什么添加 setTimeout 时行为会“改善”。我也可能遗漏了一些东西;)

    【讨论】:

    • getxhr 是全球性的,在我完成之前我不会覆盖它,所以虽然我可以将其设为本地,但我看不出它可能会产生什么不同。我确实想知道 Chrome 是否没有排队一些在重新发送之前完成的清理操作。
    • 所以你说,但你的代码说你每次调用 requestNextBroadcast 时都会覆盖它。这可能没问题——毕竟,我什至很少使用 $.ajax 的返回值
    【解决方案4】:

    评论不会格式化代码,因此作为第二个答案重新发布:

    我认为 Michael Dibbets 正在处理 $.ajax.done 的问题——延迟模式将处理推到事件循环的下一轮,我认为这是这里需要的行为。请参阅:http://www.bitstorm.org/weblog/2012-1/Deferred_and_promise_in_jQuery.html 或 http://joseoncode.com/2011/09/26/a-walkthrough-jquery-deferred-and-promise/

    我会尝试类似:

    function requestNextBroadcast() { 
      // never stops - every reply triggers next.
      // and silent errors restart via long timeout.
    
      getxhr = jQuery.ajax({
        url: "/activity",
        // dataType: 'json',
        data: "id="+channel,
        timeout: <?php echo $delay; ?> 
      });
    
      getxhr.done(function(reply){
        handleRequest(reply);
      });
    
      getxhr.fail(function(e){
        window.status="GET error " + e;
      });
    
      getxhr.always(function(){
        requestNextBroadcast();
      });
    

    注意:我很难找到有关 Promise.done 和 Promise.fail 的回调参数的文档:(

    【讨论】:

    • 你为什么不菊花链你的事件?这样一来,所有的回调事件都会被毫无延迟地注入。现在您有风险,在分配完整的处理程序之前 ajax 获取已完成并且进程不匹配。
    • 我知道...但是在看到互联网自 IE4 和 netscape 以来的发展之后,我再也没有什么让我感到惊讶的了...我看到了最不可能的事情(例如 ie 和 zoom:1 的事情) )。如果它不能以一种方式工作,它可能会以另一种方式工作,并且有时你必须做不可能的事情来实现某件事......浏览器的差异,谁不喜欢它们。
    • 另外,它可能“不太可能”,但请记住,javascript 是一个没有 web 工作者的单线程进程,当其他东西跳到前面时,所有其他执行都会延迟(一个图像滑块,一个加载栏出现, 等等...) 这样您的 getxhr.xxxx 函数可能会延迟,因为触发器触发和其他事件获得更多优先级...使用菊花链,您可以确保在文档认为它可以执行之前处理和设置链中的所有内容堆栈中的下一项。
    • 查看编辑。 POSTS 采用菊花链式连接,因此它们不会重叠。当我们处理队列的前端时,读取不能重叠,消息将等待长达 60 秒,因此不需要菊花链。
    【解决方案5】:

    也许可以通过更改推送模块设置来解决(有一些) - 你能发布这些吗?

    从我的头顶:

    • 将其设置为间隔轮询,会有点丑陋的解决它
    • 并发设置可能会有一些影响
    • 可能会使用消息存储来避免丢失数据

    我还会使用 Charles 之类的东西来查看网络/应用程序层到底发生了什么

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2011-09-20
      • 2012-02-25
      • 2011-03-25
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多