[Catalyst] How to detect cancelled requests?

Wade.Stuart at fallon.com Wade.Stuart at fallon.com
Tue Oct 28 17:52:05 GMT 2008


Stuart Watt <swatt at infobal.com> wrote on 10/28/2008 12:22:07 PM:

> Hi all,
>
> Has anyone found a neat way of detecting and handling cancelled
> requests? We have a Catalyst app that dynamically generates SQL queries
> for part of its search, some of which are long and complex, and users
> are able to create queries that can take minutes to execute. This is OK,
> except that we need users to be able to cancel those requests through
> the browser.


Hard(er) problem alert -- depending on how your app is structured.  The
only sane way I can think of to handle this is to submit the query to a
queue outside of your cat app.  this queue would then need logic to fork
out the query and check periodically for the "kill" tag in the queue entry.
upon completion the status and output can be left in a database or file for
the cat app to recover. Maybe a POE based queue would work.  This may also
help you prioritize and limit such queries.

Otherwise,  if the query is not destructive and usage is low -- is there a
reason why you can't just take the easy way out and let it finish and
ignore the output?

-Wade



>
> To add complexity to this, we are using IIS (client specification) as
> the front end, although we are trying to get a FastCGI rather than CGI
> (with ActiveState's PerlEx) engine in place. We're doing this because we
> had to use our own Perl, simply because we were getting too many
> DBI-based memory leaks in the ActivePerl and Strawberry for our indexing
> system to be able to function effectively. (Essentially, this is a
> large-scale IR type application).
>
> The Perl we use is not threaded, essentially a "5.10 with all the
> patches as of September 2008", although I'd be happy to make it threaded
> if that would help. As far as I can tell, alarm is just about capable of
> cancelling long-running database queries, and with polling, the database
> no longer seems to be the issue. However, rendering the results can take
> a while, and IIS seems to choose not to inform anyone (or us, at least)
> when the user cancels a request and the connection close is initiated.
>
> Does anyone have any experience or recommendations?
>
> All the best
> Stuart
> --
> Stuart Watt
> swatt at infobal.com
>
>
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/




More information about the Catalyst mailing list