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
fragile.
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.
Jeff,
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.
