![](https://secure.gravatar.com/avatar/7ed9784cbb1ba1ef75454034b3a8e6a1.jpg?s=120&d=mm&r=g)
On Fri, 27 Jul 2007 17:25:44 -0400, Phil Christensen <phil@bubblehouse.org> wrote:
Sorry to be so noisy lately, but I've run into another strange problem with web2.wsgi, or more likely, my understanding of it.
I'm seeing issues when the browser connection is closed uncleanly, particularly when doing a "fast reload" and clicking the reload before the first request/response has completed.
My specific issue is that when this happens, if I'm in the middle of a MySQL query (which in my app, I usually am), subsequent calls to <Cursor>.execute() are failing because the previous resultset was never freed.
This is only an issue when using web2 (or my custom twisted.web wsgi layer, which still uses web2's wsgi.WSGIHandler class). Apache/ mod_python seems to allow each request to continue to completion behind the scenes, although it makes up for it by crashing horribly in other ways.
What I'd like to know is what exactly happens when a browser closes a connection? Is there any possibility that the lost connection event has some implications further up the call chain? Could any of this somehow stop or kill the thread created in WSGIResource.renderHTTP()?
When the browser closes the connection, the server will eventually be notified that the TCP socket is closed. This translates into a call to connectionLost on the HTTP protocol implementation. This in turns stops any producer which is registered and tells the request that the connection was lost. By default, I think the request ignores this notification. WSGI is probably implemented as a producer, though. So, the producer for the application which was run to service the request will stop producing. This most likely means it will not iterate the iterator the application returned anymore. It cannot interrupt or otherwise terminate the thread the WSGI application is running in, though (since this is not an operation supported by Python threads). It has to wait for the application to produce one more piece of output, then it can exit the loop. So, it is indeed entirely possible for only part of a WSGI application to run, if the browser disappears before it finishes running. Jean-Paul