[Web-SIG] Closing long-running WSGI requests (possible?)

[Graham Dumpleton]

No, cannot really be done. This has been discussed a couple of times
on the mod_wsgi list. One such discussion is at:

  http://groups.google.com/group/modwsgi/browse_frm/thread/8ebd9aca9d317ac9

In general the same issues apply to all WSGI implementations.

Graham

2009/4/14 Chimezie Ogbuji <ogbujic at ccf.org>:
> Hello.  I have a problem with a WSGI-based SPARQL server that I have been
> unable to resolve for some time.  I was told this is the best place to ask
> :).  I'm building a SPARQL [1] server that is deployed as  WSGI/Paste
> server.  SPARQL queries are handled by the server and evaluated against a
> MySQL database using mysql-python/MySQLdb to manage the connection.
>
> My goal is to be able to allow clients to close the connection in order to
> kill queries that have been dispatched (in order to 'abort' them).
> Unfortunately, when the client kills the connection, the application is not
> signaled in any way.  So, the result is that (for long-running queries), the
> MySQL query continues to run even after the connection is closed (by
> clicking cancel in the browser for instance).
>
> I would expect that when the connection is closed at the client side, this
> should trigger a chain reaction of garbage collection (deletion of the
> application object, and all the objects attributed to it including the DB
> connection, etc.) that bottoms out in the db connection closing and MySQLdb
> killing the query as a side effect of calling __del__ on the cursor and
> database connection.  However, this is not what is happening and it appears
> that the once the result is served back to the client, the server and the
> client are completely 'disconnected' for that particular request.
>
> Am I going about his the wrong way? Does WSGI simply not have anything to
> say about such a situation ? If the problem isn't
> WSGI, is there another WSGI implementation that is known to behave as
> expected (i.e., closing the connection dispatches the deletion of the
> objects involved in the request handling)?
>
> I was told to look into keep-alive, but the specification doesn't seem to
> suggest that this would help me as it has more to do with re-using
> connections for subsequent requests rather than specifying that the server
> maintains a connection between the request and the objects involved in
> handling the request at the server.
>
> Any help would be greatly appreciated.
>
> Thanks
>
> [1] http://www.w3.org/TR/rdf-sparql-query/
>
>
> ===================================
>
> P Please consider the environment before printing this e-mail
>
> Cleveland Clinic is ranked one of the top hospitals
> in America by U.S. News & World Report (2008).
> Visit us online at http://www.clevelandclinic.org for
> a complete listing of our services, staff and
> locations.
>
>
> Confidentiality Note:  This message is intended for use
> only by the individual or entity to which it is addressed
> and may contain information that is privileged,
> confidential, and exempt from disclosure under applicable
> law.  If the reader of this message is not the intended
> recipient or the employee or agent responsible for
> delivering the message to the intended recipient, you are
> hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited.  If
> you have received this communication in error,  please
> contact the sender immediately and destroy the material in
> its entirety, whether electronic or hard copy.  Thank you.
>
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/graham.dumpleton%40gmail.com
>