I agree with Ionel
I personally wouldn't rely on "kill wsgi request".
I'd run the update in a subprocess and kill the subprocess
using a signal when the user requests (on unix, of course).
I'd also check a log written by the subprocess to see
whether it completed or not.
If you "kill the wsgi request" you have the problem
of not being quite sure whether the kill arrived in time,
among other possible difficulties, some mentioned by Ionel.
-- Aaron Watters
http://aaron.oirt.rutgers.edu/myapp/docs/W0500.quickstart
(apologies to Christian, who got this twice, I forgot to "reply all")
--- On Mon, 4/13/09, Ionel Maries Cristian <ionel...@gmail.com> wrote:
> From: Ionel Maries Cristian <ionel...@gmail.com>
> Subject: Re: [Web-SIG] Closing long-running WSGI requests (possible?)
> To: "Christian Wyglendowski" <christ...@dowski.com>
> Cc: "Chimezie Ogbuji" <ogbu...@ccf.org>, web-sig@python.org
> Date: Monday, April 13, 2009, 12:01 PM
> 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
>
>
>
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> 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/arw1961%40yahoo.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
