Static files randomly fail to load in Google Chrome

[anonymous]

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.

[Jannis Leidel]

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

[Aymeric Augustin]

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

[anonymous]

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

[Christian Hammond]

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.

[yesimon]

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.

[Jani Tiainen]

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.

[Ramiro Morales]

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

[anonymous]

OP here, I'm indeed running OS X.

[yesimon]

Chrome has marked this as a wontfix: ​http://code.google.com/p/chromium/issues/detail?id=105308

[Christian Hammond]

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.

[gansos]

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.

[yesimon]

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.

[loic84]

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

[Aymeric Augustin]

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.

[Aymeric Augustin <aymeric.augustin@…>]

In 4ff682c1ba1cd051243842bbd2feb19e75b559f3:

Fixed #18336 -- Doubled request_queue_size.

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