Corin Moss wrote:Hiya,
This probably works for the FilesystemStore, but both the JCS and
EHCache stores use their own store file - so everything is cached within
one big binary file - which means that something else has to take over
the deleting cycle.
True. This thread though was about FS store :)
You'll have to monitor last access timestamp to implement similar for jcs/ehcache/whatever.
Also add to this that when you use event based
caching you can't rely on time stamps - something could be 3 months old
in the cache but still be valid.
My point is; if it was not used in a week - you could easily delete it and it will be re-created when it is needed next time. But if resource is frequently accessed, then its access timestamp will be updated and so it will not be removed.
This approach should work just fine in 90% - or even 99% - of cases. Think of it as an analogue to LRU cleanup policy, but with preset time limit instead of preset cache size.
That's what I'm doing on the Apache side of things to actually wipe out the content of the cache after one day....
But now I kinda understand why JCS crashed on me after 6/8 hours being put on live... It's a grow-only mechanism, and given that I probably restart Cocoon on live once every 3/4 weeks (maybe longer) and we have something like 1.5 million valid URLs (150.000 articles on 11 sites), I can see why the baby can't handle it...
Time to write some code, then...
Pier
smime.p7s
Description: S/MIME cryptographic signature
