Thanks for bringing me to the light.
On 5/3/06, Graham Leggett <[EMAIL PROTECTED]> wrote:
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
again, I am in the dark: why do cache request headers may need to be
replaced or edited in the same entity?
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.
this makes sense, but I still do not understand the origin of the
problem (in-place header replacement).
Problems with cache expiry though are a real problem that mod_cache
suffers from now, and need to be fixed.
That's why I suggested a dedicated process/thread for cache
administration, which is not a good idea if too many lookups are
issued to this process on each request received.
Regards,
--
Gonzalo A. Arana
