Gonzalo Arana wrote:
Excuse my ignorance in this matter, but about the 'cache sub-key' issue, why not just use a generic cache (with some expiration model -LRU, perhaps-) with a 'smart' comparison function?
So far one of the best suggestions was from the patch posted recently, where the headers and body were in the same file, but where the headers were given "breathing room" before the cache body, so that the headers can be replaced (within reasonable limits).
What this means is that each key/data entry is now a single file again (like in 1.3), which is much easier to clean up atomically.
The problem still remains that an existing cache file's headers must be editable, without doing expensive operations like copying, and this editing must be atomic (no use one thread/process trying to serve content from the cache and halfway through, another thread tries to update the headers). This will require some form of locking, which may be too much of a performance drag, thus blowing the back-to-one-file idea out the water.
Problems with cache expiry though are a real problem that mod_cache suffers from now, and need to be fixed.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature