Re: DNS Caching class proposal

> 1) I mostly use NFS you know flock() incompatibilities and weakness. > With the mkdir() method I was able to do 1000 requests with 30 > concurrent process (apache benchmark) with no cache corruption and no > extra hashing/crc checks. That's why Cache_Lite use extra hashing tests. IMHO, it's very difficult to find a cache corruption with apache bench (but i don't know why :-(( > 2) The Cache_Lite storage format doesn't fit quiet well for this. I > won't use one file per cached domain and because each entry has its own > TTL, the Cache_Lite per file ttl is not needed. Other problem using one > file and Cache_Lite is that cached entries in ResolverCached contains > binary data, which should be encoded before the write. You can use the "automaticSerialization" option. If set to true (false by default), you can manage binary datas without problem. > 4) As I understand, Cache_Lite does not prevent to the case when the > cache is locked but the execution is aborted before reaching the unlock > operation, locking the file forever. ResolvedCached() detects that case > and cleans the lock if it's older than 30 seconds. You can set the "fileLocking" option to false if you use extra hashing tests. So, you don't need locks (and their problems) at all. > 5) Cache_Lite does not provide a garbageCollector() only a "remove all" > option. Since Cache/Lite 1.4, there is a garbageCollector option called "automaticCleaning". And the clean() method can be used as a garbageCollector (but manually) with the "old" option. > Please don't take that as an attack, just both were designed for > different purposes and environments. No problem at all :-) But the "caching process" is not as simple as it seems to be (cache corruptions, garbage collector, perf problems with thousands of cache files if you have not a hashed directory structure...). So, maybe, it would be more efficient to add your missing features into Cache_Lite...or maybe not :-) Now, you have all the elements to take your decision and I will respect it without problem ;-) -- Fabien MARTY fabien.marty@free.fr