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)

basehttp.py.patch (555 bytes ) - added by anonymous 13 years ago.

Download all attachments as: .zip

Change History (17)

by anonymous, 13 years ago

Attachment: basehttp.py.patch added

comment:1 by Jannis Leidel, 12 years ago

Triage Stage: UnreviewedAccepted

Wow, what a weird bug, accepting in general, but have to look into this further.

comment:2 by Aymeric Augustin, 12 years ago

This reminds me of #16099, but it appears to be a different bug.

comment:3 by anonymous, 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.

https://github.com/loic/django/tree/test_staticfiles

comment:4 by Christian Hammond, 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 yesimon, 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 Jani Tiainen, 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 Ramiro Morales, 12 years ago

Can the users that are experimenting this issue report their OS?. Maybe it's a OS X-specific thing?

Last edited 12 years ago by Ramiro Morales (previous) (diff)

comment:8 by anonymous, 12 years ago

OP here, I'm indeed running OS X.

comment:10 by Christian Hammond, 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 robgolding63, 12 years ago

Cc: robgolding63 added

comment:12 by gansos, 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 yesimon, 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 loic84, 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
Last edited 12 years ago by loic84 (previous) (diff)

comment:15 by Aymeric Augustin, 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 Aymeric Augustin <aymeric.augustin@…>, 12 years ago

Resolution: fixed
Status: newclosed

In 4ff682c1ba1cd051243842bbd2feb19e75b559f3:

Fixed #18336 -- Doubled request_queue_size.

This reduces random failures to load static files with Google Chrome.

Note: See TracTickets for help on using tickets.
Back to Top