On Monday 06:21 PM 8/18/2008, russell muetzelfeldt wrote:
On 19/08/2008, at 11:06 AM, John Caruso wrote:
That'd be an improvement over the current situation, but it's still
the case that AOLserver as currently shipped has a file cache
mechanism built into it which 1) may return incorrect data and 2)
is enabled by default.  Given the risk, I'd say fastpath caching
should be disabled by default rather than enabled.

if someone's application is at risk of triggering this behaviour,
that'd just delays any problem until their load is high enough that
they need to turn on fastpath - and surely that's an even worse

I'd say it's still better, because it requires explicit action on the user's part to enable the flawed caching mechanism in that case. And actually I don't think fastpath in its default configuration would be of much help in performance terms these days, given that the cache is only 5MB large and file data is typically cached by the OS anyway (and servers generally have far more RAM than they did even five years ago).

I do think this should have been considered (and steps taken to address it) when the fastpath caching mechanism was initially developed, since it's a glaring flaw. I've designed things that rely on shaky underlying assumptions in the past, but only in controlled circumstances where those assumptions were guaranteed to obtain. I can think of situations in which a caching mechanism with this type of design limitation wouldn't be an issue, but in my opinion it has no place being a default-enabled mechanism in an enterprise-grade web server.

- 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