That implies one would have extremely reliable tcp connections, and clients<br>graciously shutdown the connection and the server is notified of that.<br><br>Most of the time that doesn't happen and the solution is to continuously send <br>
keepalive packets (some small string or whatever) - I'm assuming you run<br>a batch a set of queries and you can interleave yielding some data while<br>you run that batch.<br><br>For example if your client disconnects and the servers tries to send some data<br>
it would fail - and trigger closing the app iterable.<br><br>In contrast a server that just runs some backend processing without moving <br>any data around doesn't have any way to know if the connection is still valid.<br>
<br>Then again, even if the client properly shutdown the connection the server<br>won't do anything about it if it doesn't try to do anything with the socket due<br>to the synchronous nature (I'm assuming) of the whole server/app.<br>
<br clear="all">-- ionel<br><br>
<br><br><div class="gmail_quote">On Mon, Apr 13, 2009 at 17:53, Christian Wyglendowski <span dir="ltr"><<a href="mailto:christian@dowski.com">christian@dowski.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Mon, Apr 13, 2009 at 10:40 AM, Chimezie Ogbuji <<a href="mailto:ogbujic@ccf.org">ogbujic@ccf.org</a>> wrote:<br>
> Hello. I have a problem with a WSGI-based SPARQL server that I have been<br>
> unable to resolve for some time. I was told this is the best place to ask<br>
> :). I'm building a SPARQL [1] server that is deployed as WSGI/Paste<br>
> server. SPARQL queries are handled by the server and evaluated against a<br>
> MySQL database using mysql-python/MySQLdb to manage the connection.<br>
><br>
> My goal is to be able to allow clients to close the connection in order to<br>
> kill queries that have been dispatched (in order to 'abort' them).<br>
<br>
</div>This should be doable from what I understand. From PEP 333:<br>
<br>
"If the iterable returned by the application has a close() method, the<br>
server or gateway must call that method upon completion of the current<br>
request, whether the request was completed normally, or terminated<br>
early due to an error. (This is to support resource release by the<br>
application. This protocol is intended to complement PEP 325's<br>
generator support, and other common iterables with close() methods."<br>
[1]<br>
<br>
So it sounds like you could add a close method on whatever iterable<br>
that your application returns and have it do the required resource<br>
release there.<br>
<br>
HTH,<br>
<br>
Christian<br>
<a href="http://www.dowski.com" target="_blank">http://www.dowski.com</a><br>
<br>
[1] <a href="http://www.python.org/dev/peps/pep-0333/#specification-details" target="_blank">http://www.python.org/dev/peps/pep-0333/#specification-details</a><br>
<div><div></div><div class="h5">_______________________________________________<br>
Web-SIG mailing list<br>
<a href="mailto:Web-SIG@python.org">Web-SIG@python.org</a><br>
Web SIG: <a href="http://www.python.org/sigs/web-sig" target="_blank">http://www.python.org/sigs/web-sig</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/web-sig/ionel.mc%40gmail.com" target="_blank">http://mail.python.org/mailman/options/web-sig/ionel.mc%40gmail.com</a><br>
</div></div></blockquote></div><br>