What about using epoll (or equivalent) in Linux, and kqueue in FreeBSD
to tell the kernel to notify AOLServer in change a file has changed?

That'd be a pretty easy and efficient way to discard fastpath items in
case they have been deleted and/or modified.

Just my two cents ;-) 

Juan José del Río    |  
(+34) 616 512 340    |  [EMAIL PROTECTED]

Simple Option S.L.
  Tel: (+34) 951 930 122
  Fax: (+34) 951 930 122

On Tue, 2008-08-19 at 09:20 -0700, Tom Jackson wrote:
> Andrew,
> This is not a corner case. The exact same thing could happen without
> fastpath. 
> What is that thing? That the contents of a file changes after a request
> is made and before the file is returned. In fact, there is no guarantee
> that it won't change mid-return. This is a fact of life with files on
> any filesystem. 
> In fact, with the HTTP caching mechanisms, you could fail to get
> up-to-date contents of a file, since the If-Modified-Since mechanism
> will also fail. 
> The problem here is that the application is using this static file
> handling API to serve dynamic content. Wondering why it doesn't work is
> pointless.
> Just to summarize again, this case requires that a file is created then
> destroyed and another file created within the same second that has the
> same size. Also, the original file must get into the cache, and the only
> way that can happen is for the application to treat it as a long lived
> static file. 
> We have other means to cache dynamic data, and large chunks of dynamic
> content saved as a file can avoid the fastpath cache by setting the
> cachemaxsize parameter. Writing smaller content to disk doesn't make any
> sense if your goal is speed...or security. 
> It is probably even more important to tamp down these misconceptions
> about how AOLserver works. Static and dynamic content are handled by
> different API. The reason is that it has long been recognized by the
> developers of AOLserver that different techniques are required to
> maintain high performance based upon how the content is generated, its
> expected lifespan, its size, and its potential for reuse.  
> tom jackson
> On Tue, 2008-08-19 at 03:00 -0400, Andrew Piskorski wrote:
> > On Mon, Aug 18, 2008 at 06:06:23PM -0700, 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.
> > 
> > Sounds right to me.  Either robustify Fastpath somehow against this
> > corner case, or don't have Fastpath turned on by default.
> > 

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