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.
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]>
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.