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 zero.
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.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
