Varnish 3.1 becoming 4.0 instead (?)

[Kacper Wysocki]

On Mon, Dec 5, 2011 at 1:35 PM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
>
> I've been mildly disciplined for not keeping the -dev mailing list
> in the loop, and that's perfectly true: I have not.

tsk tsk

What you are asking here elicits a response in me, and I'm sure in
many others on this list, however it is hard enough to articulate and
that may be why the list is silent on this issue.

[snip .. on streaming..]
> The thinking until now was that we would try to release Varnish 3.1
> with both of these as default-off features, and make them default-on
> feautures in 4.0

Well, there has been quite a lot of VCL breakage in Varnish over the
years, 2.0 -> 2.1 -> 3.0 has not been entirely painless, despite this
I'm pretty sure streaming support has a big thumbs up from most of us,
and the features gained have outweighed other considerations.

> However, as we work the code a couple of details and one 500 pound
> gorilla has materialized
[snip]
> The only reason why we added vcl_error{} was to avoid every vcl_fetch{}
> having to have to start with:
>
>        if (beresp.status == 503) {
>                /* do something */
>        }

> But with streaming, you can only detect failures to fetch the
> headers, once you have started to receive the body, you have committed
> to a reply to the client, and it cannot be uncommitted.

But the reply to the client may fail or hit an exception at any point,
both from the source side of the data (backend timeout) and the sink
side (client timeout), and being able to do something in VCL on these
conditions is gold.

> That makes vcl_error{} basically pointless with streaming on.
[snip]
> The way I think it will look in 4.0 is that failures to fetch
> the reponse-headers from the backend, will be reported as
> a 503 reponse in vcl_fetch{}, from where a restart will
> be possible.
>
> If you are streaming, and the body fails, you won't hear about it
> at VCL level, there will be nothing we can do about it.

> If you are not streaming, and the body fetch fails, you will
> see a 503 in vcl_deliver{}.
>
[snip]
>        return (response(812));

This may just be language aesthetics, but this is, how do we say it, fugly.

 As far as I can understand the problem it's that the introduction of
streaming makes it real hard to do a callback?

There are some use cases for vcl_error are not being considered here.
vcl_error is not just "deliver $some synthetic" but, and this is the
main kicker, it's an exception mechanism.
Even Tollef's proposed solution of using identifiers instead of status
codes is not ideal. The big advantage of vcl_error is that you can
call it from the rest of the code and also be sure you land there when
an error occurs in the request flow.

> So if we do streaming in 3.1 as planned, I'll have to find some way
> to hack up vcl_error{} to still work as we are used to, and I'm
> increasingly finding that more trouble than it is worth and leaning
> more and more towards the 4.0 option where we can do away with
> vcl_error{} and avoid all the complications.
>
> This email represents your chance to come up with really good
> arguments for why we should not simply skip 3.1

Hopefully I've articulated some arguments for keeping vcl_error that
don't just involve the standard gripes with losing vcl compatability.

-K