My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 59881: Hang - local development with App Engine SDK
12 people starred this issue and may be notified of changes. Back to list
Status:  WontFix
Owner:  willchan@chromium.org
Closed:  Jun 2012
Cc:  willchan@chromium.org, mbel...@chromium.org

Restricted
  • Only users with Commit permission may comment.


Sign in to add a comment
 
Reported by els...@google.com, Oct 19, 2010
Chrome Version       : 7.0.517.41 (Official Build 62167) beta - running on GNU/Linux
URLs (if applicable) : localhost
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: OK
  Firefox 3.x: OK
IE 7:
IE 8:

What steps will reproduce the problem?
1. Run the appengine SDK against the attached project
2. Open http://localhost:port/
3. Refresh (if it didn't hang the first time)


What is the expected result?

You should be able to refresh and the page should finish loading every time. One thing I've noticed is that if I remove the second resource from the HTML page this problem goes away.

What happens instead?

The spinner spins and the page never loads.

Please provide any additional information below. Attach a screenshot if
possible.

In the terminal where I'm running the app engine SDK if I hit CTRL-C I get the following: 
INFO     2010-10-20 00:09:28,550 dev_appserver.py:3283] "GET / HTTP/1.1" 200 -
^C----------------------------------------
Exception happened during processing of request from ('127.0.0.1', 52389)
Traceback (most recent call last):
  File "/usr/lib/python2.6/SocketServer.py", line 281, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/lib/python2.6/SocketServer.py", line 307, in process_request
    self.finish_request(request, client_address)
  File "/usr/lib/python2.6/SocketServer.py", line 320, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/home/elsigh/src/google_appengine/google/appengine/tools/dev_appserver.py", line 3091, in __init__
    BaseHTTPServer.BaseHTTPRequestHandler.__init__(self, *args, **kwargs)
  File "/usr/lib/python2.6/SocketServer.py", line 615, in __init__
    self.handle()
  File "/usr/lib/python2.6/BaseHTTPServer.py", line 329, in handle
    self.handle_one_request()
  File "/usr/lib/python2.6/BaseHTTPServer.py", line 312, in handle_one_request
    self.raw_requestline = self.rfile.readline()
  File "/usr/lib/python2.6/socket.py", line 406, in readline
    data = self._sock.recv(self._rbufsize)
KeyboardInterrupt

At first I really thought this was a bug with App Engine's dev_appserver and the SDK (it may be!) but trying it with Firefox, I don't have this issue.
gae-bomb-example.zip
1.7 KB   Download
Oct 19, 2010
#1 evan@chromium.org
This seems vaguely like that deadlock we had in our test runner, that I think we worked around by disabling preconnect or whatever, right?
Status: Assigned
Owner: ero...@chromium.org
Cc: willc...@chromium.org mbel...@chromium.org
Labels: -Area-Undefined Area-Internals
Oct 19, 2010
#2 willchan@chromium.org
I think Evan is right here.  The root cause is probably due to the dev_appserver being lame.  It's possible for a user agent (such as Chrome) to open multiple connections to the server, but to send a request over the second connection before the first connection.  Note that the client and server-side perceptions of "first" aren't necessarily the same due to network variability (dropped SYNs, etc.).  A lame server might assume that the first connection will always have a response, and block on a read() on that socket, rather than trying to process any requests on any other sockets.  This is clearly broken.

When the server locks up like this, can you open up a second browser and try to hit it?  Does that browser work?  If not, it definitively points to the server as the problem.
Oct 19, 2010
#3 venkatar...@chromium.org
 Issue 59880  has been merged into this issue.
Oct 19, 2010
#4 mike%belshe.com@gtempaccount.com
Preconnect right now is quite often opening two connects; with Will's recent fix (and my work to plumb it into preconnect), this problem will go away.

For the single-connection servers of the world, note that due to packet loss, it's always possible to have this out-of-order problem occur. It's just more rare.
Oct 23, 2010
#5 adam.sah
thanks! for jumping on this-- I was hitting this as well and it's super annoying: happens on virtually every connect and I've had to switch to Firefox.  It's definitely lameness in appengine, i.e. it's hanging.  I also tested --disable-preconnect and that fixed this problem.

hope this helps,
adam
(former google eng; techlead on gadgets)

Oct 25, 2010
#6 eroman@chromium.org
Closing per above comments. Upcoming versions of chrome will have some mitigation for this.
Status: WontFix
Feb 1, 2011
#7 wkornew...@gmail.com
Which version would that be? It's still hanging. :(
Feb 1, 2011
#8 eroman@chromium.org
Will, any ideas? I remember a while back you changed the ordering for unused idle sockets to mitigate single-threaded server cases.
Status: Assigned
Owner: willc...@chromium.org
May 17, 2011
#9 mal@google.com
(No comment was entered for this change.)
Owner: willchan@chromium.org
May 1, 2012
#10 asadov...@gmail.com
This seems to have been fixed recently -- I was seeing it until today when I updated to 18.0.1025.162 (Linux).
https://code.google.com/p/googleappengine/issues/detail?id=4716 seems to corroborate this.
Jun 21, 2012
#11 willchan@chromium.org
I think this is obsolete. Ping if I'm wrong.
Status: WontFix
Labels: Internals-Network
Oct 13, 2012
#12 bugdro...@chromium.org
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Labels: Restrict-AddIssueComment-Commit
Mar 10, 2013
#13 bugdro...@chromium.org
(No comment was entered for this change.)
Labels: -Area-Internals -Internals-Network Cr-Internals Cr-Internals-Network
Sign in to add a comment

Powered by Google Project Hosting