handling failure in varnish

[Martin Blix Grydeland]

I would consider a VMOD that requires calls into it in a specific order,
and all of those calls having to be made for it not to blow up, to be a
poorly written VMOD. When we have  REQ_PRIV variables, it should be
possible to write VMODs that don't have that requirement, and they will be
able to clean up after themselves properly on those callbacks (which would
be called even if wrk->failed). So I'm not sure the VMOD use case is the
right reason to go for no-ops on workspace exhaustion.

Actually as a VMOD writer, I think I would find the sudden no-op behavior
more surprising than a VCL method ending early, and I fear we'll end up
with VMODs that crash in strange ways on workspace exhaustion that way when
the data it expected to be written inside of the same VMOD method wasn't
there.

I believe a strict exit from the VCL method before the next statement on an
error condition would be preferable to the no-ops.

Martin




On 25 June 2014 23:54, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

>
> One of the longest standing items we have on our wish list is a more
> graceful and more informative handling of "out of workspace" types of
> errors.
>
> I've been looking at that a bit and have started to mitigate the
> asserts that currently litter these cases.
>
> But I still having come up with a really good mental model of how
> to do it.
>
> My current leaning is that we will register these failures in a
> flag om the worker-thread (wrk->failed ?) so that we only have
> to look one place to see if we have already failed.
>
> ... because, we probably cannot just fail out of a VCL method
> because we cannot tell if mess up a VMOD that way, imagine
> something like:
>
>         foobar.firstpart();
>         set req.http.foobar = foobar.makeheader();
>         foobar.secondpart();
>
> If we just fail out of the VCL when the second line fails to get
> the necessary storage, we cannot know if the last line is necessary
> in order to clean properly up in the VMOD.
>
> In general I prefer all struct http.* operations should become
> no-ops after a failure, as a general "latch errors" principle,
> and obviously an VSL should be emitted that tells where things
> went haywire, in particular which workspace did so.
>
> Any ideas and insights are most welcome...
>
> --
> 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.
>
> _______________________________________________
> varnish-dev mailing list
> varnish-dev at varnish-cache.org
> https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
>



-- 
<http://varnish-software.com>*Martin Blix Grydeland*
Senior Developer | Varnish Software AS
Cell: +47 21 98 92 60
We Make Websites Fly!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-dev/attachments/20140626/19bce8ea/attachment.html>