[Catalyst] How to detect cancelled requests?

[Jonathan Rockway]

* On Wed, Oct 29 2008, Stuart Watt wrote:
> [snip]
> Our ideal would be a non-buffered model, where results are displayed
> incrementally, and where user requests can cancel a query, at worst
> when the next hit is about to be displayed. Since we fetch hits and
> render them incrementally, this should just work.
>
> It seems likely that IIS is most of the problem. Personally, I have
> never been happy with it (especially with ISAPI/PerlEx), but we are
> required to use IIS at least, and with much of the documentation
> relating to Catalyst on IIS being slightly on the sketchy side, it is
> hard to know how to improve the position. Ideally, we could use the
> following

This seems like a perfect time to use something like Comet.  The user
submits a query and immediately gets back a page that says "query is
running" that updates itself with the results as they come in.  It can
also have a cancel button to explicitly cancel the query.  (You can run
the cancel code when they close the tab also.)

It will complicate your architecture a bit, but it should also be a nice
UI improvement.  It is nice when you don't have to tell your clients to
reconfigure their browser to not time out when waiting for your
database.  (I've been there.)

Anyway, if you do this, you will have explicit messages for everything,
and you won't have to guess what SIGPIPE or whatever really means.  You
will have a "user_clicked_the_cancel_button" event, and you can deal
with that accordingly.

All this assumes that you have some sort of job queue for running the
long query.  It may seem like a lot of overhead for the really fast
queries, but it probably won't be in practice.

> [more snipping]
> 3. Any experience with trying to get HTML passed to IIS in a
> non-buffered manner -- it all seems buffered right now

You are using $c->res->write for this, right?

Regards,
Jonathan Rockway

--
print just => another => perl => hacker => if $,=$"