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

[Ionel Maries Cristian]

That implies one would have extremely reliable tcp connections, and clients
graciously shutdown the connection and the server is notified of that.

Most of the time that doesn't happen and the solution is to continuously
send
keepalive packets (some small string or whatever) - I'm assuming you run
a batch a set of queries and you can interleave yielding some data while
you run that batch.

For example if your client disconnects and the servers tries to send some
data
it would fail - and trigger closing the app iterable.

In contrast a server that just runs some backend processing without moving
any data around doesn't have any way to know if the connection is still
valid.

Then again, even if the client properly shutdown the connection the server
won't do anything about it if it doesn't try to do anything with the socket
due
to the synchronous nature (I'm assuming) of the whole server/app.

-- ionel



On Mon, Apr 13, 2009 at 17:53, Christian Wyglendowski
<christian at dowski.com>wrote:

> On Mon, Apr 13, 2009 at 10:40 AM, Chimezie Ogbuji <ogbujic at ccf.org> wrote:
> > 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).
>
> This should be doable from what I understand.  From PEP 333:
>
> "If the iterable returned by the application has a close() method, the
> server or gateway must call that method upon completion of the current
> request, whether the request was completed normally, or terminated
> early due to an error. (This is to support resource release by the
> application. This protocol is intended to complement PEP 325's
> generator support, and other common iterables with close() methods."
> [1]
>
> So it sounds like you could add a close method on whatever iterable
> that your application returns and have it do the required resource
> release there.
>
> HTH,
>
> Christian
> http://www.dowski.com
>
> [1] http://www.python.org/dev/peps/pep-0333/#specification-details
> _______________________________________________
> 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/ionel.mc%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/web-sig/attachments/20090413/c2f26f80/attachment.htm>