req.hash_control_* variables
Kristian Lyngstøl
kristian at varnish-software.com
Tue Aug 10 14:20:23 CEST 2010
Hey Martin (and -dev)
The idea we want to implement is for varnish to be able to do
controlled cache misses to update the content, and allow Varnish to
ignore busy-objects in a controlled (through VCL) manner.
The features are only marginally different.
I already implemented return(refresh), but have backed it out again,
because we've decided to go for a more generalized approach and use a
variable instead of a return type. I attached the patch as a
reference. If nothing else, it should give you a vague idea.
The use case for ignoring the busy object is to avoid a race when you
have two Varnish servers asking each other for data when the client
isn't the other Varnish server. IE:
Time Action
1. client->v1 GET /foo
1. client->v2 GET /foo
2. v1->v2 GET /foo
2. v2->v1 GET /foo
3 v2: Already fetching /foo (from v1). Wait for it.
3. v1: Already fetching /foo (from v2). Wait for it.
So far, the naming suggestion is a req.hash_control_always_miss =
{0,1} and req.hash_control_ignore_busy = {0,1}. We did discuss briefly
if we should have a general bitmap or not, but I think we ended up
going for a uint8_t for each of them instead for now.
For VCL, a snippet from vcl_fetch might look like:
if (client.ip ~ varnish1) { set req.hash_control_ignore_busy = 1; }
or:
if (client.ip ~ purgeservice && req.http.X-purge == "true") { set
req.hash_control_always_miss = 1; }
I'll go through VCL in more detail with you and Yves tomorrow, so
you'll have at least a few minutes between VCL 101 and coding it ;)
So take a shot if it seems attainable and interesting.
- Kristian
PS: I CC'ed varnish-dev, as there is no reason not to. I'm going to
default to cc'ing -dev for everything related to development.
More information about the varnish-dev
mailing list