[PATCH] backend conditional requests first release

[Geoff Simmons]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 3/2/11 11:46 PM, Poul-Henning Kamp wrote:
> (I talked with Geoff on IRC about one aspect of the patch which
> didn't look nice, the tendency for the ttl/grace stuff to leak
> all over the place.)
> 
> I've spent the evening trying to untangle ttl/grace and generalize it
> in a way that will make adding the conditiona_timeout (that is sort
> of a long word, isn't it ?) easier to fit in.
> 
> You should now be able to add the field to struct exp, add the
> variables to the VCC python file, macro-calls in cache_vrt_var.c
> and hide the rest of it in cache_expire.c
> 
> Note the call to EXP_Grace() in update_object_when(), you'll need
> to update that as well.  (I'll take care of -spersistence, please
> don't touch that)

I've integrated the update and added the functionality for IMS. Two
issues have come up, one that I think is minor, the other a troubling
suspicion that I haven't been able to prove.

We want to be able to do this:

    sub vcl_fetch {
        set beresp.ttl = 0s;
        set beresp.cond_ttl = 1m;
        return (deliver);
    }

... to decide that an object should not be used to answer any more
requests, but could be used for IMS. EXP_set_ttl(0) sets all of the
timers to -1, including cond_ttl, as we discussed. If cond_ttl then gets
set to non-zero, HSH_Lookup() should be able to find it as a possible
stale_obj. The problem was that HSH_Lookup() couldn't get past this line
in the loop:

	if (o->exp.ttl <= 0.0)
		continue;

So I changed that to:

	if (o->exp.ttl <= 0. && o->exp.grace <= 0.
	    && o->exp.cond_ttl <= 0.)
		continue;

Then it works as expected, all test cases pass.

We also want to be able to say:

    sub vcl_hit {
        set obj.ttl = 0s;
        set obj.cond_ttl = 1m;
    }

... to do the same thing with the object in cache. EXP_set_ttl(0) also
sets all the timers to -1, and EXP_set_ttl() calls EXP_Rearm(). Now I
have EXP_set_cond_ttl() doing both of these as well.

I worry about a race condition here. After EXP_set_ttl(0) calls
EXP_Rearm(), it seems to me that the object may be cleared from cache
before EXP_set_cond_ttl() gets a chance to change cond_ttl and call
EXP_Rearm() again.

I've tried to make that happen by having VCL busily evaluate a lot of
expensive regexes between the set obj.ttl and set obj.cond_ttl calls. So
far, all of the test cases I've tried do the right thing anyway. But
don't we have a risk here? Or am I missing something that would prevent
the problem?


Best,
Geoff
- -- 
** * * UPLEX - Nils Goroll Systemoptimierung

Schwanenwik 24
22087 Hamburg

Tel +49 40 2880 5731
Mob +49 176 636 90917
Fax +49 40 42949753

http://uplex.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (SunOS)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJNcDEtAAoJEOUwvh9pJNUR4j4P/2tIyCMj6apj0zIRRYJcJyoI
BfKcE2in/t5zkYPuP3GfiH+cPB+qM8QsjiVi/pj1vGrCYhJBUaPJmjNwR6TyTnF/
b/F9GwWkdbbQXmbEGHKWg1RYA977TSZ4SLCzyr5aszwnoHaDjS0ZCsYjLquczFyF
wkim9sknJnuBAfDMNKO+JZ1DWP1HczE7KJXXW1Kv0zYIPFdoUzQNfJpu45YUYn6/
WWgzYVQKbU15q2CEF60dFDYqMDed7AJ1NXZI2KuMSd4gjBylZR8+YO0wHSs3REL7
QWakbOBGWgraot6/t6EUuJtZMNNM5ZKa4ZumdAyUUTGJF8UktDXIm3JdDJV9/hRC
5LajAtd5dtq9ebHzn73bNdMPXajbV+tjmyq3EDpYEdLJUFGWpxU3oZgpg6appZtx
KFYpqj+PW26ZxoGLfzpRFD8wvfjt75YLsS0llkTq0t7/su44QmfchW7nwp53fJji
MWByIdir03KFPZQhZgQksKzvW4XFRLxBUF/16Al9/46BOkYnAW/soPWzGOxMHpZe
02a6q5Us1ZhVf6CjvdixhXU8bxuqTC++mVmJrNhedCqLRbDsjqQrSrjqPi2ar7N8
9CPq356NIEps6bh6wcKt4msKCNMalfX2vwZq6yodEBDPjsqaCFUGiuYyh1cBodIZ
ADoqSw51EGQ3lyV3rSxB
=l233
-----END PGP SIGNATURE-----