Django 1.5 runserver hangs in Chrome

[Nikolas Stevenson-Molnar]

I've just updated to Django 1.5 and am running into a problem when using Chrome with the Django devlopment server (and staticfiles). One particular page which loads a lot of static content consistently hangs in Chrome (works fine in Firefox). This seems similar to two resolved issues: https://code.djangoproject.com/ticket/16099 and https://code.djangoproject.com/ticket/18336. Except that I've waited several minutes and the resources haven't finished loading. I've increased request_queue_size as suggested in the second issue (first to 10, then 20, then 50) with no change.

I'd chalk this up entirely as a Chrome problem, except that if I switch back to Django 1.4 (changing nothing else), everything goes back to working fine. So what changed about runserver in Django 1.5 that might cause this? And more importantly, how do I get around it? I'm running everything on Windows 7 with Django 1.5.1 and the latest version of Chrome.

Thanks,
_Nik

[Nikolas Stevenson-Molnar]

Also, while Chrome is spinning, I can open Firefox and load pages (including the problem page) just fine. So it's not that the server is overloaded or anything like that...

_Nik

[eXt]

I can confirm this issue. Exactly the same problem here.

[Sven Bröckling]

Hi,

Chrome sometimes does really strange things. I use chrome with a
disabled cache for development (Open Developer Tools, click on the
settings menu, first option) which resolves this kind of problems for me.

Regards
Sven

> I can confirm this issue. Exactly the same problem here.

[Larry Martell]

On Mon, Jul 8, 2013 at 5:00 AM, Sven Bröckling <sv...@broeckling.de> wrote:
> Hi,
>
> Chrome sometimes does really strange things. I use chrome with a disabled
> cache for development (Open Developer Tools, click on the settings menu,
> first option) which resolves this kind of problems for me.

I'm frequently emptying my cache, so this would help me a lot. But I
can't find the setting menu when I open the Developer Tools - where is
that?

Thanks!
-larry

>> I can confirm this issue. Exactly the same problem here.
>> Also, while Chrome is spinning, I can open Firefox and load pages
>> (including the problem page) just fine. So it's not that the server
>> is overloaded or anything like that...
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users...@googlegroups.com.
> To post to this group, send email to django...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[François Schiettecatte]

Its the little gear at the bottom right, took me a while to find it.

F.

[Larry Martell]

On Mon, Jul 8, 2013 at 9:16 AM, François Schiettecatte
<fschiet...@gmail.com> wrote:
> Its the little gear at the bottom right, took me a while to find it.

Got it! Thanks!

[Nikolas Stevenson-Molnar]

Hi Sven,

Thanks for the suggestion. Unfortunately, this didn't resolve the issue
for me. Chrom is still hanging on that page. It loads most of the
resources, then hangs indefinitely while requesting several images.

If I close the tab, I get a stack trace in the Django log (connection
aborted) which shows the last call to be to socket.sendall(). It's
bizarre; what is going on? I can load all those images fine in a
separate tab, but loading them with the page creates problems...

_Nik

[Nikolas Stevenson-Molnar]

After a lot of dead ends, I finally found the problem! The cause is the switch to using CompatibleStreamingHttpResponse in the django.views.static.server view. Previously, the view simply read the whole file into memory and returned a regular HTTP response. The StreamingHTTPResponse class uses the file iterator to return data, which in turn returns one line per iteration. I'm not at all sure why, but this seams to cause a problem when requesting many files at once (e.g., Chrome).

In order to verify that this was the problem, I solved the issue by adding a file_chunk_iterator function (yields 1024 bytes per iteration, rather than one line like the standard Python file iterator), and changing the response in the serve view from this:

response = CompatibleStreamingHttpResponse(open(fullpath, 'rb'), content_type=mimetype)

to this:

response = CompatibleStreamingHttpResponse(file_chunk_iterator(open(fullpath, 'rb')), content_type=mimetype)

The iterator function looks like this:

def file_chunk_iterator(f, size=1024):
    while True:
        chunk = f.read(size)
        if chunk:
            yield chunk
        else:
            return

On 7/3/2013 5:39 PM, Nikolas Stevenson-Molnar wrote: