我在jquery中有以下查询。它正在读取使用Nginx的长查询模块设置的Nginx订阅/发布对的发布地址。
函数requestNextBroadcast（）{ //永不停止 - 每个回复都会触发下一个。 //通过长时间超时重启静默错误。 getxhr = $ .ajax（{ url：/ activity， // dataType：'json'， data：id =+ channel，超时：46000，//必须长于最大心跳才能在无提示错误后触发错误：函数（jqXHR，textStatus，errorThrown）{ alert（Background failed+ textStatus）; / /应该永远不会发生 getxhr.abort（）; requestNextBroadcast（）; //再次尝试}， success：function（reply，textStatus，jqXHR）{ handleRequest（reply）; //这是正常结果。 requestNextBroadcast（）; } }）; }该代码是聊天室的一部分。发送的每条消息均以空字符（具有200 / OK）回复，但数据已发布。这是数据返回时读取订阅地址的代码。
使用超时时间，聊天室中的所有人都会每隔30到40秒发送一条简单消息，即使他们没有输入任何内容，所以有足够的数据这个代码要读取 - 每40秒至少2个或更多的消息。
这个代码在EI和Firefox中是100％稳定的。但在Chrome浏览器中有一个读取大约5次失败。
当Chrome出现故障时，它会有46秒的超时时间。
日志显示任何时候都有未完成的活动网络请求。
我一直在抓取此代码为3天，尝试各种想法。每次IE和Firefox工作正常，Chrome都会失败。
我看到的一个建议是让呼叫同步 - 但这显然不可能，因为它会将用户界面锁定太久。
编辑 - 我有一个部分解决方案：代码现在是这个
$ p $ function requestNextBroadcast（） { //永不停止 - 接下来会触发每个回复。 //通过长时间超时重启静默错误。 getxhr = jQuery.ajax（{ url：/ activity， // dataType：'json'， data：id =+ channel，超时：<？php echo $ delay;？>， error：function（jqXHR，textStatus，errorThrown）{ window.status =GET error+ textStatus; setTimeout （requestNextBroadcast，20）; //再次尝试}， success：function（reply，textStatus，jqXHR）{ handleRequest（reply）; //这是正常结果 setTimeout（requestNextBroadcast，20）; } }）; }结果有时会延迟回复，直到发生$ delay（15000）然后，排队的消息太急躁地到达。我一直无法使用这种新的安排让信息丢失（仅在网络关闭的情况下进行测试）。
我非常怀疑拖延是由于网络问题造成的 - 所有机器都是我的一台真机中的虚拟机，并且我的本地局域网中没有其他用户。
编辑2（星期五2:30 BST） - 更改了代码以使用承诺 - 并且操作的POST开始显示相同的症状，但接收方开始工作正常！ （???? !!! ???）。 这是POST例程 - 它处理一系列请求，以确保一次只有一个请求未完成。
function issuePostNow（）{ //在30至40秒内将心跳重置为丢失发送setTyping（false） 。 clearTimeout（dropoutat）; dropoutat = setTimeout（function（）{sendTyping（false）;}， 30000 + 10000 * Math.random（））; //并发送 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（）; //移除此任务 if（（txt！= null）&&（txt.length> ; 0））{ alert（Error：unexpected post reply：+ txt）} issuePostNow（）; }）; postxhr.fail（function（）{ alert（window.status =POST error+ postxhr.statusText）; issuePostNow（）; }）;关于8个调用handlechat.php的动作将超时并显示警报。一旦警报结束，所有排队的消息到达。
我还注意到，在它写下其他人会看到的信息之前，手语呼叫停顿了。我想知道，如果它可能是一些奇怪的处理会话数据的PHP。我知道它仔细排队调用，以便会话数据没有损坏，所以我一直小心使用不同的浏览器或不同的机器。只有2个PHP工作线程，但PHP不用于处理/活动或静态内容的服务。
我也认为它可能是nginx工作者或php处理器的短缺，所以我提出了这些。现在要让事情失败变得更加困难 - 但仍然有可能。我的猜测是/活动电话现在失败了30次，并且根本不放弃邮件。
感谢您的输入。
发现摘要。 这是Chrome中的一个bug，已经在代码中占了一段时间。 2）运气好的话，显示为未发送的POST，当超时后，Chrome将处于重复POST成功的状态。 3）用于存储从$ .ajax返回的变量（ ）可以是本地的或全球的。新的（承诺）和旧的格式调用都会触发该错误。 4）我还没有找到解决方法或避免该错误的方法。
Ian
解决方案我正在进行Ajax调用，以便每秒从服务器获取时间。显然，Ajax调用必须是异步的，因为如果不是，它会在超时时冻结接口。但是，一旦Ajax调用中的一个失败，每个后续的调用都是如此。我首先尝试将超时设置为100ms，并且在IE和FF中运行良好，但在Chrome中无法运行。我最好的解决方案是将类型设置为POST，然后用chrome解决了我的错误：
setInterval（function（）{ $ .ajax（{ url：'getTime.php'，类型：'POST'， async：true， timeout：100，成功：function（）{console.log（success）;}， error：function（）{console.log（error）;} }）; }， 1000）;更新： 我相信这里的实际潜在问题是Chrome的缓存方式。看起来，当一个请求失败时，该失败被缓存，并且因此后续请求永远不会发生，因为在启动后续请求之前，Chrome将获得缓存失败。如果您转到Chrome的开发人员工具并转到网络标签并检查每项请求，就可以看到这一点。在发生故障之前，ajax会每秒发出一次getTime.php请求，但是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查询，但为了这样做， type选项必须是GET或HEAD，这就是为什么我删除'类型：'POST''（GET为默认值）。
I have the following query in jquery. It is reading the "publish" address of an Nginx subscribe/publish pair set up using Nginx's long polling module.
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(); } }); }The code is part of a chat room. Every message sent is replied to with a null rply (with 200/OK) reply, but the data is published. This is the code to read the subscribe address as the data comes back.
Using a timeout all people in the chatroom are sending a simple message every 30 to 40 seconds, even if they don't type anything, so there is pleanty of data for this code to read - at least 2 and possibly more messages per 40 seconds.
The code is 100% rock solid in EI and Firefox. But one read in about 5 fails in Chrome.
When Chrome fails it is with the 46 seconds timeout.
The log shows one /activity network request outstanding at any one time.
I've been crawling over this code for 3 days now, trying various idea. And every time IE and Firefox work fine and Chrome fails.
One suggestion I have seen is to make the call syncronous - but that is clearly impossible because it would lock up te user interface for too long.
Edit - I have a partial solution: The code is now this
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); } }); }Result is sometimes the reply is delayed until the $delay (15000) happens, Then the queued messages arrive too quicly to follow. I have been unable to make it drop messages (only tested with netwrok optomisation off) with this new arrangement.
I very much doubt that delays are dur to networking problems - all machines are VMs within my one real machine, and there are no other users of my local LAN.
Edit 2 (Friday 2:30 BST) - Changed the code to use promises - and the POST of actions started to show the same symptoms, but the receive side started to work fine! (????!!!???). This is the POST routine - it is handling a sequence of requests, to ensure only one at a time is outstanding.
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(); }); } }About one action in 8 the call to handlechat.php will timeout and the alert appears. Once the alert has been OKed, all queued up messages arrive.
And I also noticed that the handlechat call was stalled before it wrote the message that others would see. I'm wondering if it could be some strange handling of session data by php. I know it carefully queues up calls so that session data is not corrupted, so I have been careful to use different browsers or different machines. There are only 2 php worker threads however php is NOT used in the handling of /activity or in the serving of static content.
I have also thought it might be a shortage of nginx workers or php processors, so I have raised those. It is now more difficult to get things to fail - but still possible. My guess is the /activity call now fails one in 30 times, and does not drop messages at all.
And thanks guys for your input.
Summary of findings.
1) It is a bug in Chrome that has been in the code for a while. 2) With luck the bug can be made to appear as a POST that is not sent, and, when it times out it leaves Chrome in such a state that a repeat POST will succeed. 3) The variable used to store the return from $.ajax() can be local or global. The new (promises) and the old format calls both trigger the bug. 4) I have not found a work around or way to avoid the bug.
Ian
解决方案I had a very similar issue with Chrome. I am making an Ajax call in order to get the time from a server every second. Obviously the Ajax call must be asynchronous because it will freeze up the interface on a timeout if it's not. But once one of the Ajax calls is a failure, each subsequent one is as well. I first tried setting a timeout to be 100ms and that worked well in IE and FF, but not in Chrome. My best solution was setting the type to POST and that solved the bug with chrome for me:
setInterval(function(){ $.ajax({ url: 'getTime.php', type: 'POST', async: true, timeout: 100, success: function() { console.log("success"); }, error: function() { console.log("error"); } }); }, 1000);Update: I believe the actual underlying problem here is Chrome's way of caching. It seems that when one request fails, that failure is cached, and therefore subsequent requests are never made because Chrome will get the cached failure before initiating subsequent requests. This can be seen if you go to Chrome's developer tools and go to the Network tab and examine each request being made. Before a failure, ajax requests to getTime.php are made every second, but after 1 failure, subsequent requests are never initiated. Therefore, the following solution worked for me:
setInterval(function(){ $.ajax({ url: 'getTime.php', cache: false, async: true, timeout: 100, success: function() { console.log("success"); }, error: function() { console.log("error"); } }); }, 1000);The change here, is I am disabling caching to this Ajax query, but in order to do so, the type option must be either GET or HEAD, that's why I removed 'type: 'POST'' (GET is default).
更多推荐
Chrome未处理jquery ajax查询
发布评论