CODEWITHSUNDEEP
javascriptajaxgoogle-chromewebspheregoogle-chrome-devtools
MattDiamant
MattDiamant

Reputation: 8771

Chrome Network Web Developer Tool tab says Dojo AJAX requests are taking around 44 years to complete

16027.8

The Chrome Network Tab in the Web Developer Tools shows that a bunch of my AJAX requests are taking 16027.8 days to complete. This is... not how long they are taking.

I can replicate this on multiple machines, and in both development and production environments. This happens for all Dojo AJAX requests that are happening onload. It doesn't happen for other webapp or 3rd party requests (like signin AJAX or facebook).

What is going on? Is our server somehow screwing this up? Is it a bug in chrome dev tools (it almost certainly is, right?), and if so, is there anything that can be done about it? It makes the visual waterfall pretty useless, as you can imagine.

Edit: Upon new information, this seems to be a common problem with IBM Websphere Commerce sites. What about the server or code could be causing this? Look here for examples:

http://www.ikea.com/us/en/catalog/categories/departments/kitchen/# http://www.lavieenrose.com/webapp/wcs/stores/servlet/LVER_10052_10001_-1 http://www.ferragamo.com/shop/en/usa

Edit 2: This issue is fixed in the newest version of Chrome.

Upvotes: 8

Views: 1069

Answers (2)

Viktor Aseev
Viktor Aseev

Reputation: 698

This issue is not related to web framework or server. Issue affects Chrome browser version 31.0.1650.57.

Now issue is fixed and will be delivered with next stable channel update. Fix diff

If you need fix urgently, you can update to dev channel version. Instructions

See this issue for more details.

Upvotes: 7

Scott Heaberlin
Scott Heaberlin

Reputation: 3424

Very odd. Able to recreate on Chrome 31.0.1650.57 on OSX Mavericks as well. Tested w/ ikea link, noticed Chrome reported 16028.7 days, 41ms latency for resource /us/en/iows/tealium.

Charles proxy shows these headers:

HTTP/1.1 304 Not Modified
Content-Type: application/json
Last-Modified: Mon, 18 Nov 2013 18:34:51 GMT
Cache-Control: public, max-age=7200
Date: Sat, 23 Nov 2013 00:32:26 GMT
Connection: keep-alive
Vary: Accept-Encoding

The proxy app (Charles) reports no such odd time - it shows 40ms.

The lavieenrose.com link caused Chrome to report time of 16028.7 days as well... that seems to be in common. Charles shows:

HTTP/1.1 200 OK
Date: Sat, 23 Nov 2013 00:46:37 GMT
Server: IBM_HTTP_Server
Last-Modified: Tue, 19 Jun 2012 13:05:34 GMT
ETag: "5c487f-1a15-4c2d2f01a0380"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 1738
Content-Type: application/x-javascript

My conclusion is this isn't a server response or headers issue. I think this is a Chromium or WebKit dev tools issue.

Here's HEAD of the dev tools JS object that represents the http request which rendered by the Network tab:

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/devtools/front_end/NetworkRequest.js

I'm wondering about the math in set endTime():

set endTime(x)
{
    if (this.timing && this.timing.requestTime) {
        // Check against accurate responseReceivedTime.
        this._endTime = Math.max(x, this.responseReceivedTime);
    } else {
        // Prefer endTime since it might be from the network stack.
        this._endTime = x;
        if (this._responseReceivedTime > x)
            this._responseReceivedTime = x;
    }
},

No answers just yet, but perhaps someone with more insight into what WebKit/Chromium DevTools may see this...

Upvotes: 2

Related Questions