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.
Vadim
Corin
-----Original Message----- From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: Friday, 22 October 2004 12:39 p.m. To: [EMAIL PROTECTED] Subject: Re: FilesystemStore broken???
Corin Moss wrote:
Hiya,
This does indeed cause problems now that true persistence is working. Given that no space is actually recovered from the persistent store (even when items are invalid) the disk-cache grows - even across shutdown /startup cycles. I guess the store janitor will need to be modified to enable removal of expired / invalid content.
It's not its job. Moreover, it does not know what is stored in the Store and
whether it is valid or not. Way easier solution is to add a line to crontab:
rm `find -atime +7`
So only files not used at all in a week or more will get erased. Easy, efficient, no coding required.
Vadim
