Varnish 3.1 becoming 4.0 instead (?)

[Tollef Fog Heen]

]] Poul-Henning Kamp 

Hi,

> 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.
> 
> That makes vcl_error{} basically pointless with streaming on.

I'd call it «less useful», not useless, since quite often the problem is
that your backend is overloaded and not able to give us an answer in a
reasonable amount of time.  Still something we should see if we can fix,
though.

> 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.

As long as you can detect whether a 503 is internally generated or not,
that's fine.

> 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.

Reasonable.


[...]

> 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.

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.

> 	The new workspace means that we will have three workspaces
> 	in total:
> 		sess->ws  	holds req.*
> 		ws->ws	  	holds resp.*
> 		busyobj->ws	holds bereq.* and beresp.*

Does this mean the lifetime of the workspaces are the same as the
lifetime of those objects too?

>         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? 

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