[Catalyst] Catalyst::Response callbacks? Need to reap auto-generated files on disk after they are served.

[Wade Stuart]

On Thu, Sep 2, 2010 at 3:21 PM, Tommy Butler <ace at tommybutler.me> wrote:

>  Hello all :D
>
> In looking at the documents for Catalyst::Response I've recently
> re-discovered some great little ways that Catalyst provides for you to
> stream out big files.  Awesome.
>
> Now I'd like to take *a bit futher* though.  Presently, in the process of
> serving one kind of request, my cat app creates a large file and then
> streams it back out to the browser.  Ideally I'd like to clean up this fi=
le
> after it gets cooked up and streamed out.  I'd like to utilize some kind =
of
> callback so that after the file has been completely consumed by the remote
> client, I can go ahead and safely remove it from server-side disk.
>
> Without such a fix, I'm going to have to start running cron jobs on the
> temp directory and just deleting output files older than a certain arbitr=
ary
> expiration age.  While doing so is easy enough, I'd rather go on with
> Catalyst managing its own content as it has done for me up to this point.
>
> What are your thoughts?  Has anyone done something like this who would be
> willing to share their solution, or are there others among us who would be
> so kind as to share some ideas of their own?
>
>
Tommy,

     A little feedback from my personal experience.  I have tried this many
times before and never had this work as a long term solution.  There are a
few big areas of gotchas that always seem to pop up:

The data build is cpu,disk,network,database intensive and
get multiple requests for the same build -- on a lightly loaded app this may
seem very unlikely,  but as user base grows and the app becomes utilized
many times this turns into the case.  Really depends on the content (unique
keyed delivery based on an order may not be an issue,  a directory zip up
from a file service may be).

The user's browser times out,  they download the file and forget or lose it,
 and for whatever reason they come back to get it (instantly with a new
request or in a few minutes).

The connection fails and the cleanup never is executed (or the app crashes
or restarts while builds/requests are in cycle).

All of these require a more robust cache, and post cleanup system then just
the after request hook.  conceptually when you look at it this way you will
still be stuck with a cron type service (maybe in addition to what you talk
to above) without real data to act against besides TTL on the create/modify
date....


Kindest,
-Wade




> Thanks,
> --
> Tommy
>
>
> _______________________________________________
> 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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100903/b4f58=
2a9/attachment.htm