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 <christ...@dowski.com>wrote: > On Mon, Apr 13, 2009 at 10:40 AM, Chimezie Ogbuji <ogbu...@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@python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: > http://mail.python.org/mailman/options/web-sig/ionel.mc%40gmail.com >
_______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
