httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Edmundsson <>
Subject Re: mod_cache responsibilities vs mod_xxx_cache provider responsibilities
Date Mon, 18 Sep 2006 07:35:09 GMT
On Sun, 17 Sep 2006, Graham Leggett wrote:

> 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.
> Thinking about this some more I do see a race during purging - a cache thread 
> could read the header, the purge deletes header and body, and then the cache 
> thread reads the body, and interprets the missing body as "the body is still 
> coming".

The easiest way to deal with this might be to have a timeout, if the 
body hasn't shown up in $timeout time then something went bad, 
DECLINE, meaning that the cache layer thinks it should cache the file 
and acts accordingly. You actually want this fallback anyway, and it's 
probably enough to deal with the purge-problem. The purge should 
delete the oldest unused entries anyway, so the chance of hitting that 
case shouldn't be too common.

And yes, since this scheme only might cause on-disk stray files that 
can be cleaned up by purging I can agree that it'll work. However, I 
strongly believe that the purging should not have to read each header 
file the way that htcacheclean currently does it since it poses such a 
strain on the cache filesystem. A file system traversal should be 

Anyhow, I can probably rather easily adapt our patches to do it this 
way if that's what people want. I'm not entirely sure what the gain 
would be though, since it's a tad more housekeeping work and double 
the number of inodes to traverse during a purge...

But, that is future work. I haven't had any comment of the current 
patch of mine yet (lfs-config) so I'm not entirely sure of whether it 
seems OK and I should proceed with the next patch or what. I'm not 
that well endowed in all API:s involved, and stuff that looks right to 
me might have a much better Apachier solution so I don't want to get 
carried away creating huge patchsets to having the first one rejected 
because my coding style sucks... However, I can understand if you want 
a complete patch that solves the lfs issues, but then you'll have to 
tell me since I'm not a mind reader ;)

  Niklas Edmundsson, Admin @ {acc,hpc2n}      |
  ************ <--- tribbles playing follow-the-leader

View raw message