Code

Opened 2 years ago

Closed 15 months ago

#18336 closed Bug (fixed)

Static files randomly fail to load in Google Chrome

Reported by: anonymous Owned by: nobody
Component: HTTP handling Version: master
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 2 years ago.

Download all attachments as: .zip

Change History (17)

Changed 2 years ago by anonymous

comment:1 Changed 2 years ago by jezdez

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

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

comment:2 Changed 2 years ago by aaugustin

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

comment:3 Changed 2 years ago by 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

comment:4 Changed 19 months ago by chipx86

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 Changed 19 months ago by 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.

comment:6 Changed 19 months ago by jtiai

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 Changed 19 months ago by ramiro

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

Version 0, edited 19 months ago by ramiro (next)

comment:8 Changed 19 months ago by anonymous

OP here, I'm indeed running OS X.

comment:9 Changed 19 months ago by yesimon

comment:10 Changed 17 months ago by chipx86

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 Changed 16 months ago by robgolding63

  • Cc robgolding63 added

comment:12 Changed 16 months ago by 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.

comment:13 Changed 16 months ago by 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.

comment:14 Changed 15 months ago by 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
Last edited 15 months ago by loic84 (previous) (diff)

comment:15 Changed 15 months ago by aaugustin

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 Changed 15 months ago by Aymeric Augustin <aymeric.augustin@…>

  • Resolution set to fixed
  • Status changed from new to closed

In 4ff682c1ba1cd051243842bbd2feb19e75b559f3:

Fixed #18336 -- Doubled request_queue_size.

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.