> [12:13:56.871] GET http://www.jaxa.jp/shared/js/htv3_rss.js [HTTP/1.1 404 Not Found > 302671ms] Hmm... I see it come in near-instantly with wget or in Chrome. Why is it taking us 5 minutes to decide that its's a 404? Smells like some sort of timeout getting hit, and therefore a networking issue... Patrick, ideas?
Component: General → Networking: HTTP
But yes, given the really slow response rendering is blocked on that script....
Regression window: Good: http://hg.mozilla.org/mozilla-central/rev/7d7d075d58a3 Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1b2pre) Gecko/20081111 Shiretoko/3.1b2pre ID:20081111032821 Bad: http://hg.mozilla.org/mozilla-central/rev/8242c6adbf63 Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1b2pre) Gecko/20081112 Namoroka/3.1b2pre ID:20081112034733 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7d7d075d58a3&tochange=8242c6adbf63 Suspected: db2dd52d47c1 Blake Kaplan — Bug 458440 - Turn speculative parsing back on and clean up the code a little. r+sr=jst
I confirmed in local build, Last Good: d11e76e6fab9 First Bad: db2dd52d47c1
That's really odd. Why would speculative parsing affect this?
Umm, If I disable cache, The page is displayed instantly in Firefox15.0.1 and Nightly18.0a1 as well. browser.cache.memory.enable;false browser.cache.disk_cache_ssl;false browser.cache.disk.enable;false
Hmm. Is it possible that if our speculative fetch gets a really slow response somehow it locks the cache and then the real fetch can't go? That still leaves the question of why the speculative fetch has a slow response. And why we don't coalesce them in the scriptloader, if that's what's going on.
FYI, The description of Comment #3 and Comment#4 is for first load... When I try to open the page in a 2nd new tab, it is reproduced in a "Good"build.
Created attachment 666225 [details] HTTP Log when I opened attached sample html (https://developer.mozilla.org/en-US/docs/HTTP_Logging#Windows)
nick and michal are the cache experts..
(In reply to Boris Zbarsky (:bz) from comment #7) > Hmm. Is it possible that if our speculative fetch gets a really slow > response somehow it locks the cache and then the real fetch can't go? That > still leaves the question of why the speculative fetch has a slow response. > And why we don't coalesce them in the scriptloader, if that's what's going > on. If we have to requests, A and B, that try to load the same resource, and request A opens a cache entry, then request B will wait for request A to mark the cache entry as "valid" before request B can read from the cache. If request A has to validate the entry (If-Last-Modified, If-None-Match), then it won't mark that entry valid until it gets a response back. If it gets a cacheable response back, then it won't mark the entry valid until it has received, and written to the cache, the entire response. The whole time, request B will be there, waiting for request A to say "OK, go ahead and use that cache entry."
Sure. The question is why request A is taking 5 minutes. It shouldn't.
Now, I cannot reproduce this bug. If this is hidden by the website side and we still have this bug, feel free to reopen this bug.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.