On Wednesday 10:58 AM 8/20/2008, Jim Davidson wrote:
With the fix below with resolution for mtime at 1 second and the
"grace period" at 2 seconds I  can see how it would work but it would
make me a bit queasy -- fixes which have assumptions of timing can be

Perhaps, but not in this case. This is just another way to circumvent use of the cache on an object-by-object basis (like the size restriction that's already there), which recognizes the fact that using mtime as a determiner of uniqueness is limited by the fact that mtime has a granularity of only one-second. As for fragility, the fastpath algorithm is fragile *now*, thanks precisely to its assumptions about timing. This very simple change removes the bulk of that fragility.

Again, this whole issue is interesting and the problem report quite
subtle, justifying some sort of defensive fix but using ns_returnfile
for short, dynamic content still seems like the wrong approach.

Whether or not that's so, the fact is that everyone on this list appeared to share the same utterly natural assumption that "ns_returnfile X" really will return file X--which turns out to be untrue solely because of fastpath caching's design limitation. This fix resolves that design limitation in any standard circumstance.

BTW: Which OS is re-using inodes so quickly?

The ext3 filesystem on Linux and the ufs filesystem on Solaris both re-use inodes in this way.


On Wednesday 10:56 AM 8/20/2008, Jeff Rogers wrote:
John Caruso wrote:
BTW, Jeff, the scenario you'd outlined that you thought would trip this up...:
   13:50:21 - create file
   13:50:21 - serve file (gets cached)
   13:50:21 - delete file
   13:50:21 - create file again (reuses inode)
   ... time passes ...
   13:55:11 - serve file
...actually wouldn't, because the file would NOT be cached in the second line. The whole point of this strategy is that a file won't be cached if it's been modified within the threshold time (2 seconds in the patch above).

Fine, then change that first timestamp to 13:50:18 [...]

No, you're still not understanding how the patch works. If you change the first timestamp to 13:50:18, the file will indeed be cached at 13:50:21--but with an mtime of 13:50:18. When the new file is served at 13:55:11, it will *not* result in a cache hit because the mtime will be different. That's exactly how the patch fixes this issue.

If your patch solves your problem, that's great, and that's the whole point of OSS. But it does nothing to solve the problem generally and has negative side effects, so I think it would be a mistake to add it to the general distribution.

I'm surprised you're taking such an all-or-nothing view now, given that you started out being open to discussion. This patch certainly does solve the problem generally--in all but what I'd say are pathological cases, and certainly in any standard usage (like the various examples I've posted). And it does it by directly addressing the fastpath algorithm's reliance on mtime, which has only one-second granularity.

- John

AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> 
with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Reply via email to