Opened 13 years ago
Closed 12 years ago
#18336 closed Bug (fixed)
Static files randomly fail to load in Google Chrome
Reported by: | anonymous | Owned by: | nobody |
---|---|---|---|
Component: | HTTP handling | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | robgolding63 | Triage Stage: | Accepted |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I've noticed while using Google Chrome that frequently (once every 2 or 3 refresh) some of my static files fail to load, it can be anything: an image, a .js file, etc. Opening that file directly always work, reloading the page usually work as well. I couldn't reproduce this behavior with Firefox.
This is happening with the default options for the runserver of django.contrib.staticfiles.
I figured this probably had to do with either a timeout or the size of the request queue, possibly both. I tried setting request_queue_size to 10 (default is 5) as demonstrated in the attached file and it completely solve the issue. I the tried setting it to 1 and it makes the issue systematic.
I tried to find how many concurrent requests chrome does and found the following:
http://code.google.com/p/chromium/issues/detail?id=12066
http://code.google.com/p/chromium/issues/detail?id=44491
Unless I'm missing something, Chrome actually use less concurrent requests than Firefox. A value of 10 for request_queue_size does seem to solve my problem completely, but I wouldn't know what should be the actual best value.
Attachments (1)
Change History (17)
by , 13 years ago
Attachment: | basehttp.py.patch added |
---|
comment:1 by , 12 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:3 by , 12 years ago
I made a test project to demonstrate the behavior, here with a request_queue_size of 1, each refresh seems to load a different set of pictures.
comment:4 by , 12 years ago
I'm curious if this has still been a problem for anyone. I've been noticing this lately with recent versions of Chrome, and can confirm that the attached patch solves it (though, it feels like a bandaid to me).
I can reliably reproduce this, so if there's anything I can do to help in debugging this, please let me know.
comment:5 by , 12 years ago
Yes this is a problem for me as well with Chrome 23 on OS X Mountain Lion when there are a lot of concurrent staticfiles requests.
comment:6 by , 12 years ago
I had the same problem. It happened exactly at the spesific location and only with Chrome. I managed to get runserver working by adjusting request_queue_size.
It's not a problem for other browsers.
comment:7 by , 12 years ago
Can the users that are experimenting this issue report their OS?. Maybe it's a OS X-specific thing?
comment:9 by , 12 years ago
Chrome has marked this as a wontfix: http://code.google.com/p/chromium/issues/detail?id=105308
comment:10 by , 12 years ago
I'm also on MacOS X.
To do any actual development, I have to patch basehttp.py every time I upgrade Django, in each virtualenv. If there were a way to at least override this in some form globally, I could live with it, but for the moment, it's a complete pain and leads to odd, sometimes very subtle bugs.
comment:11 by , 12 years ago
Cc: | added |
---|
comment:12 by , 12 years ago
I've also been experiencing this (Django 1.5, Mac OS 10.8, Chrome 25). In some cases it completely locks up Chrome (tab dies). Other times random static files fail to load. In addition, I've seen very similar behavior in AppEngine's dev_appserver (also based on Python's SocketServer module) , and I'm inclined to think request_queue_size is the culprit.
comment:13 by , 12 years ago
BTW I got this fix merged into django-devserver, which is a drop in replacement for runserver in dev.
https://github.com/dcramer/django-devserver/pull/70
This bug is probably going to be a WontFix on both Chrome and Django ends.
comment:14 by , 12 years ago
For anyone looking for a quick fix that doesn't require patching Django or installing a third party app: you can monkey patch WSGIServer from settings.py.
A queue size of 10 has worked really well for me since I opened this ticket, but with this in settings.py you can easily increase the value to match your needs.
from django.core.servers.basehttp import WSGIServer WSGIServer.request_queue_size = 10
comment:15 by , 12 years ago
I could eventually reproduce this, on OS X.8 with Chrome, with the test project provided by Loic in comment 3 and WSGIServer.request_queue_size
set to 1.
I'm not sure why the original path and devserver resort to monkey-patching instead of simply defining request_queue_size
on WSGIServer
.
comment:16 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Wow, what a weird bug, accepting in general, but have to look into this further.