John Caruso wrote:

I'd agree that that's the intent, but the caching is hidden within ns_returnfile and it's not clear at all from the user's perspective that this alligator is lurking in the swamp. Using ns_returnfile in this way may not be the best approach in any particular situation, but it's nonetheless a completely valid usage and isn't contraindicated in any AOLserver docs I've seen.

This then is the real fix: mention it in the docs. I put a blurb on the appropriate wiki pages; feel free to suggest something better :)
The docs in the distribution should be updated too.

It happens to be used in ns_returnfile since that is the normal use case. On unix the fastpath cache is keyed off the dev/inode probably to keep the hash key shorter. Windows doesn't have device and inode numbers so it uses the filename as the hashkey, so it wouldn't run into this problem.

No, it can still easily run into this problem--it's just that the file name needs to be the same in both cases (which actually did apply in my client's case, and caused confusion in the early debugging of the problem, since the assumption was that using the same file name and/or path name was the source of the problem).

The system needs to be free to do some things to improve performance with the understanding that the user needs to be aware of those things or risk bad behaviour. I wouldn't call it an unreasonable assumption that a file with the same name (and same modtime etc) is the same file. You can run into a very similar problem with NFS (i.e., attribute caching causing a modified file to appear not so) and people have learned to deal with that.

- making ns_unlink flush the entry from the fastpath cache

Nope, since the file can be removed via (e.g.) exec rm.

True, but I'd still put this in the "system needs to be able to ..." category above. The system does some things and the developer should be aware of those things.

I don't think your suggestion of waiting for cache entries to age a second or two would work well, it just moves the race condition around and adds a whole lot of disk activity when a busy server is warming up - static files might be read a few dozen times instead of once.

Nope, not at all. The only files that would get read more than once would be those that were served within one second of being generated--which wouldn't apply to any content that fits the definition of "static".

It would work in your exact case, where the file is always removed immediately after being served and generated. But if not, it would still come up with the wrong answer.

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

In this case the file modtime is more than a few seconds old, but the cached mtime, inode, etc. are still matching the file on disk, so the stale cache entry would get delivered.

There is also at least one clever optimization where "static" content does get served within a second of being created, where the 404 page is used to generate something like an image from something like a database and writes it to a file where it is subsequently served by fastpath.

So this is actually a fairly non-intrusive fix. The main limitation is that it relies on the file timestamps and the server timestamps being synchronized, which may not always be true. But I can't think of a better solution. Simply put, fastpath caching is inherently broken because it's not possible to guarantee that the file in question really should be served from cache (again, short of a cache-defeating checksum).

The same can be said about nearly any caching system: it is unable to handle changes in the data that happen outside of the cache's control or knowledge. This is just the bargain you make when you use a cache.

But my point here wasn't to ask about potential workarounds but to highlight the issue itself, since I haven't seen it mentioned before.

I think you highlighting it is most of the fix. From there, get the caveat inserted into the documentation and the knowledge into the community so that the next person who runs into this problem will have an easier, or at least less frustrating time solving it.


AOLserver -

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