Varnish 3.1 becoming 4.0 instead (?)

Tollef Fog Heen tfheen at
Fri Dec 9 14:26:54 CET 2011

]] "Poul-Henning Kamp" 

> In message <87ty5bmfsv.fsf at>, Tollef Fog Heen writes
> :
> >As long as you can detect whether a 503 is internally generated or not,
> >that's fine.
> That is an interesting idea, but why would that be important ?

It's really part of a somewhat larger problem which currently is to
figure out why you ended up in vcl_error.  Was it because of a backend
timeout?  Backend giving ECONNREFUSED?  Something else?  We don't know,
and it might be important to know, either because we want to log it or
we want to handle different errors in different ways.

So, if you know where an error comes from, you have more information and
that's useful.

> >I don't think the 3.1 vs 4.0 naming is particularly important, but I
> >know you feel much stronger about that than I do.
> I think we owe the users to clearly mark when we muck about with
> VCL syntax.  If consensus is that 3.1 is sufficient warning, then
> fine by me.

To the extent historical precedent matters, we did the obj → beresp
change for vcl_fetch in 2.0 → 2.1.  In my head, we don't break stuff in
3.0.x (but we can add bits), we can break between 3.0 and 3.1.  The
distinction isn't particularly important to me, we are in no risk of
running out of integers.

> >>         Eventually sess->ws should only exist when sessions do not
> >>         wait, and then worker->ws can then be eliminated and sess->ws
> >> 	contain both req.* and resp.*  (Hopefully in 4.0)
> >
> >Won't sess->ws always exist (and probably be where most vmods will store
> >their data) or do you actually mean what you wrote?
> I usually mean what I write, but I may not have thought it through before
> I wrote it :-)
> My reasoning for the above is that large sites have very high numbers
> of sessions waiting to see if the client will send more requests and
> we need to reduce the memory pressure of that.

Oh, I think I might have misunderstood what you meant, then.  I
understood what you wrote to be that sess->ws would go away when a
client would wait for a backend fetch for instance, and that did not
make any sense at all.  (If you go to vcl_hit, you can't use req.* in
vcl_deliver would be one of the fallouts.)

Dropping or resetting sess->ws between each request would be fine with

Tollef Fog Heen
Technical lead, Varnish Software
t: +47 21 98 92 64

More information about the varnish-dev mailing list