Opened 5 years ago

Closed 5 years ago

#16099 closed Bug (fixed)

Development web server sometimes hangs with Chrome

Reported by: jseims@… Owned by: Steve Lacy
Component: HTTP handling Version: 1.3
Severity: Normal Keywords:
Cc: Steve Lacy Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I'm able to reproduce on the default Amazon ec2 tiny instance (Linux ip-10-112-95-131 2.6.35.11-83.9.amzn1.i686 #1 SMP Sat Feb 19 23:41:56 UTC 2011 i686 i686 i386 GNU/Linux).

If I run the dev server and hit a page with Chrome, it will often hang for exactly 60 seconds establishing a network connecting. In other words, Chrome reports the connection as "pending", and for 60 seconds nothing happens (i.e., my code doesn't run, strace doesn't say anything unusual), and then everything proceeds fine.

Behavior goes away if I use another browser, or if I run django through apache.

Let me know if I can provide additional info.

Attachments (2)

multithreaded.diff (2.2 KB) - added by Steve Lacy 5 years ago.
Patch to enable multithreaded runserver, some small doc fixes as well.
multithreaded-2.diff (791 bytes) - added by james Turnbull 5 years ago.
Patch dealign only with the chrome issue, cleanly applies

Download all attachments as: .zip

Change History (16)

comment:1 Changed 5 years ago by anonymous

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset

comment:2 Changed 5 years ago by Aymeric Augustin

Resolution: invalid
Status: newclosed

This is a Chrome bug, acknowledged here: https://code.google.com/p/chromium-os/issues/detail?id=13043

comment:3 Changed 5 years ago by anonymous

What do you think about making the Django server multi threaded, as this comment states:

it's incredibly easy to mix multithreading into python's simple HTTP server:

class ThreadedHTTPServer(ThreadingMixIn, HTTPServer):

def init(self, server_address, HandlerClass):

HTTPServer.init(self, server_address, HandlerClass)

I made the web server in client/cros/httpd.py multithreaded in this way a few days ago.

Version 0, edited 5 years ago by anonymous (next)

comment:4 Changed 5 years ago by ShawnMilo

Probably not going to happen. From the docs:

DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through security audits or performance tests. (And that's how it's gonna stay. We're in the business of making Web frameworks, not Web servers, so improving this server to be able to handle a production environment is outside the scope of Django.)

(link: https://docs.djangoproject.com/en/1.3/ref/django-admin/)

There are plenty of other easy options, including install gunicorn and running manage.py run_gunicorn instead of runserver.

comment:5 Changed 5 years ago by anonymous

Got it.

Maybe some documentation around using the dev server? FWIW, I lost a couple days debugging this issue :(

comment:6 Changed 5 years ago by Aymeric Augustin

Resolution: invalid
Status: closedreopened
Triage Stage: UnreviewedDesign decision needed
UI/UX: unset

This will not be fixed in Chrome, and the problem was mentioned again in #16249. It seems that we're going to have to do something.

comment:7 Changed 5 years ago by Aymeric Augustin

Component: UncategorizedHTTP handling
Type: UncategorizedBug

comment:8 Changed 5 years ago by Steve Lacy

I'm using Chrome 12.0.742.60 beta on Ubuntu 11.04 and can reproduce this easily by starting a totally blank Django project, and attempting to visit "http://localhost:8000/" using Chrome's Incognito mode.

I've looked at the strace, and the hang is right after the accept() of the new connection. The HTTP server does a recvfrom() on the new socket, and Chrome never seems to write the request.

The sequence looks like this (from "strace -T -f -o /tmp/strace.out python ./manage.py runserver --noreload": Each call is annotated with it's runtime in seconds in <>'s, so take a look at the 1st call to recvfrom() which takes 60 seconds to complete.

[...]
17271 select(4, [3], [], [], {0, 500000}) = 0 (Timeout) <0.500664>
17271 select(4, [3], [], [], {0, 500000}) = 0 (Timeout) <0.500648>
17271 select(4, [3], [], [], {0, 500000}) = 1 (in [3], left {0, 285305}) <0.214843>
17271 accept(3, {sa_family=AF_INET, sin_port=htons(49463), sin_addr=inet_addr("127.0.0.1")}, [16]) = 4 <0.000059>
17271 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 <0.000075>
17271 recvfrom(4, "", 8192, 0, NULL, NULL) = 0 <60.004065>
17271 shutdown(4, 1 /* send */)         = 0 <0.000145>
17271 close(4)                          = 0 <0.000107>
17271 select(4, [3], [], [], {0, 500000}) = 1 (in [3], left {0, 499996}) <0.000081>
17271 accept(3, {sa_family=AF_INET, sin_port=htons(49464), sin_addr=inet_addr("127.0.0.1")}, [16]) = 4 <0.000078>
17271 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 <0.000081>
17271 recvfrom(4, "", 8192, 0, NULL, NULL) = 0 <0.000033>
17271 shutdown(4, 1 /* send */)         = 0 <0.000099>
17271 close(4)                          = 0 <0.000027>
17271 select(4, [3], [], [], {0, 500000}) = 1 (in [3], left {0, 499997}) <0.000018>
17271 accept(3, {sa_family=AF_INET, sin_port=htons(49465), sin_addr=inet_addr("127.0.0.1")}, [16]) = 4 <0.000023>
17271 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 <0.000014>
17271 recvfrom(4, "GET / HTTP/1.1\r\nHost: localhost:8000\r\nConnection: keep-alive\r\nCache-Control: max-age=0\r\nUser-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.60 Safari/534.30\r\nAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\nAccept-Encoding: gzip,deflate,sdch\r\nAccept-Language: en-US,en;q=0.8\r\nAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3\r\n\r\n", 8192, 0, NULL, NULL) = 397 <0.000022>

comment:9 Changed 5 years ago by Steve Lacy

Cc: Steve Lacy added

This is an annoying issue for development, as it's really convenient to be logged in as your admin user in an Incognito window while you interact as a "regular" user in the non-Incognito mode.

So, not a production issue, but certainly hinders development as now I have to log in and out to switch back and forth between users (or run two instances of Chrome with different user profile directories, which is more of a hassle)

comment:10 Changed 5 years ago by Steve Lacy

Okay, after reading the Chrome bug (justifying why they're doing it) I think that adding the ThreadingMixIn might be a good idea. Shall I submit a patch?

comment:11 Changed 5 years ago by Aymeric Augustin

I still haven't seen where RFC2616 says that HTTP servers MUST accept more than 1 connection :)

Jokes asides, yes, we should probably add the ThreadingMixIn. A patch will be appreciated.

comment:12 Changed 5 years ago by Steve Lacy

Owner: changed from nobody to Steve Lacy
Status: reopenednew

comment:13 Changed 5 years ago by Steve Lacy

Has patch: set

Changed 5 years ago by Steve Lacy

Attachment: multithreaded.diff added

Patch to enable multithreaded runserver, some small doc fixes as well.

Changed 5 years ago by james Turnbull

Attachment: multithreaded-2.diff added

Patch dealign only with the chrome issue, cleanly applies

comment:14 Changed 5 years ago by Jannis Leidel

Resolution: fixed
Status: newclosed

In [16427]:

Fixed #16099 -- Enabled threading for the runserver management command and added a --nothreading option to disable it if needed. This should help Google Chrome users because it opens more than one connection speculatively.

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