Possible race condition between ban and fetch within esi processing

[Moritz Krinke]

Hello,

i'm adding bans (lurker friendly) in vcl using headers set by the backend.
I'm also using ESI includes. Usually the bans match a specific esi include.
I'm banning before the call to process the request for esi includes.

Usage example: "You have 2 unread notifications" -> click -> backend marks
notifications as read, backends add header for varnish -> varnish adds ban,
requests new partial -> "you have 0 unread notifications"

This works quite fine. But sometimes it doesnt.
Varnish seems to deliver the old cached partial rather than fetching a new
one from the backend.
This does not happen a lot and i havent found a way yet to reproduce it.

One could write a small programm to do stresstest and prove this problem,
but before i do that i would like to know if you can confirm that there
might occur such a race condition (maybe from own experience, or you know
the code)

vcl example:

sub vcl_fetch {
  ban("obj.http.x-url ~ /some/uri");
  set beresp.do_esi = true;
}

im using varnish 3.0.0 (havent upgraded yet because of the bug about the
ban lurker) and my ban list is usually below 200.


Thanks a lot,

Moritz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20120210/ebe70dc8/attachment.html>