httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: mod_cache responsibilities vs mod_xxx_cache provider responsibilities
Date Sun, 17 Sep 2006 19:41:08 GMT
Niklas Edmundsson wrote:

> However, I don't see how you can do a lockless design with multiple 
> files and an index that can do:
> * Clients read from the cache as files are being cached.
> * Only one session caches the same file.
> * Header/Body updates.
> * No index/files out-of-sync issues. Ever.

It's easy - simply treat the header file as a "single file". If the 
header file exists, the entry is either cached or being cached. The 
existence or non existence of a body file is meaningless in the context 
of the cache without a header file.

If the body file doesn't exist, it's 99.999% of the time going to be 
because the lead thread that is caching the file hasn't got round to 
creating it yet - simply wait around for the file to exist and continue 
as normal. In other words a body file that does not exist is treated as 
a body file of zero length. This should happen rarely enough in practice 
that the code path to detect and deal with the file-not-found error 
should not cause a performance penalty.

The header file is always deleted first in a purge, the body file is 
deleted afterwards at leisure. When a header file is created, the body 
file is created afterwards ensuring any previous file is reset to length 

Cache purges would delete the header and then the body. And body's 
floating around without headers are orphaned files and can be deleted 
during a purge anyway.

> The current mod_disk_cache seems to be designed for small files and 
> enough memory to hide the problems by the design.

These don't look like design problems, but rather just run of the mill 
bugs. The cache for example should definitely not try and load the 
cached file into RAM first, this has a simple fix.


View raw message