> -----Original Message----- > From: AOLserver Discussion [mailto:[EMAIL PROTECTED] On > Behalf Of Jim Davidson > Sent: Tuesday, August 19, 2008 8:39 PM > To: AOLSERVER@LISTSERV.AOL.COM > 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.
