grace for all

[Joshua Frankamp]

Hello,

I would like to propose a objective to your roadmap. Both of these
build on the idea of grace.

1. Grace for All w/ Backend Fill. Three requests hit varnish
simultaneously. The leader gets punished, as grace only applies to the
latter two. They are the lucky ones, but the first must wait. I would
propose giving all three grace, _and_ when the item has been
retrieved, it can go to /dev/null after populating the cache through
vlc_fetch. It stands to reason that if the graced content is good
enough for #2 and #3, it must be also valid for #1. There are
considerations here, and it complicates because you have two code
paths emerging from one, essentially spawning another to do the
backend. I would imagine this as another grace option off by default.

2. vlc_recv should be able to call miss in addition to pass and
lookup. This will allow a use to force a cached item to refresh under
certain circumstances. For example if I have a special process hit
varnish and provide req.http.X-Cache-Builder I could choose to jump
from vlc_recv to miss, thereby forcing a backend lookup, that would
replace cache without _any_ real user getting the misfortune of
missing cache. This would NOT require async processing or thread
splitting as option 1, but would allow those of us who want to keep
cache fresh for our users to build it. In our case, we already have a
system that can crawl our own site with special headers, and it can
afford to go slow.

Either of these extend grace to all in a manner of speaking, no
request deserves to be punished. :-)

Note: I have searched the archive before posting, and I saw several
references to people misunderstanding grace or wanting prefetch to be
implemented and hoping for features like these. The developer
responses were mostly "it doesn't work like that" which I understand.
I am suggesting the idea is still important, but perhaps there are
other ways to accomplish something. #2 seems straitforward and
relatively side effect free.

Thanks,
- Joshua Frankamp