> -----Original Message-----
> From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On
> Behalf Of Jim Davidson
> Sent: Tuesday, August 19, 2008 8:39 PM
> Subject: Re: [AOLSERVER] Data "corruption" with fastpath caching
> Your right, the code snippet below could trip over a race condition as
> you've described.  But, that's not reason enough to change the
> fastpath, it's reason to better document the behavior so folks don't
> write code that uses ns_returnfile for temporary, dynamic content.
> Although fastpath takes care to be correct in most cases (e.g.,
> stat'ing the file on each request and serializing read on cache miss),
> the "fast" in fastpath is because it's primarily designed to return
> simple static content with minimal overhead.
> BTW:  I believe the ns_returnfile command didn't use the fastpath
> originally -- I think it just opened and sent the content.  It was
> changed because folks asked for it to go faster I think -- can't
> recall.

This sounds like the problem.  Not a bug with fastpath, but a questionable 
decision to take an apparently generic command and apply a situation-specific 
optimizer to it that returns bad results when applied outside of its design 
parameters.  It seemed like a valid assumption at the time, just as John's code 
seemed to be making valid assumptions, but it just seems to have led to asses 
being made left and right.

Is there any way to make ns_returnfile's use of fastpath configurable, and turn 
_that_ off by default?  Or would that be essentially the same as just turning 
fastpath off entirely?  I must confess my ignorance of where fastpath gets used.

Titi Ala'ilima
Lead Architect
MedTouch LLC
1100 Massachusetts Avenue
Cambridge, MA 02138
617.621.8670 x309

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