VCL storage discussion summary

[Federico Schwindt]

In other words, for cache insertions default / no setting means RR and NULL
means failure?

I believe that'd work.

About this:

> If at the end of v_b_r{} beresp->storage is non-NULL, we use that stevedore
and only that stevedore.

If someone sets the wrong storage, because e.g. they had a typo, we will
fail the request or fallback to Transient?


On Tue, Oct 11, 2016 at 9:12 PM, Poul-Henning Kamp <phk at phk.freebsd.dk>
wrote:

> --------
> In message <CAJV_h0bnbgUL-P43_UyX8q_RFV06if1SjPHo21Y4g+H-ME6QcA@
> mail.gmail.com>
> , Federico Schwindt writes:
>
> >Regardless of the RR, any comments or guidelines to move this forward?
>
> Having read the thread again, I suggest:
>
>         Before vcl_backend_response{} we point beresp->storage to the next
>         stevedore RR-wise. (Today we do it later, because it is a hint).
>
>         If at the end of v_b_r{} beresp->storage is non-NULL, we use that
>         stevedore and only that stevedore.
>
>         If at the end of v_b_r{} beresp->storage is NULL, we take it to
>         mean storage failure and we 50x.
>
>         That means you can still salvage inside v_b_r{}:
>
>                 beresp->stevedore = vmod.forklift();
>                 if (!beresp->stevedore) {
>                         beresp->stevedore = Transient;
>                         beresp->uncacheable = True;
>                 }
>
>         For compatibility, if VCL sets beresp->storage_hint, and the string
>         is a stevedore name, we *also* set beresp->storage, but on failure
>         we leave it alone.
>
> I belive that gives the semantics you desire in a POLA compliant fashion ?
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20161012/3d8686e3/attachment.html>