<div dir="ltr">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.<div>
<br></div><div>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.</div>
<div><br></div><div>I believe a strict exit from the VCL method before the next statement on an error condition would be preferable to the no-ops.</div><div><br></div><div>Martin<br><div><br></div><div><br></div></div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On 25 June 2014 23:54, Poul-Henning Kamp <span dir="ltr"><<a href="mailto:phk@phk.freebsd.dk" target="_blank">phk@phk.freebsd.dk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
One of the longest standing items we have on our wish list is a more<br>
graceful and more informative handling of "out of workspace" types of<br>
errors.<br>
<br>
I've been looking at that a bit and have started to mitigate the<br>
asserts that currently litter these cases.<br>
<br>
But I still having come up with a really good mental model of how<br>
to do it.<br>
<br>
My current leaning is that we will register these failures in a<br>
flag om the worker-thread (wrk->failed ?) so that we only have<br>
to look one place to see if we have already failed.<br>
<br>
... because, we probably cannot just fail out of a VCL method<br>
because we cannot tell if mess up a VMOD that way, imagine<br>
something like:<br>
<br>
foobar.firstpart();<br>
set req.http.foobar = foobar.makeheader();<br>
foobar.secondpart();<br>
<br>
If we just fail out of the VCL when the second line fails to get<br>
the necessary storage, we cannot know if the last line is necessary<br>
in order to clean properly up in the VMOD.<br>
<br>
In general I prefer all struct http.* operations should become<br>
no-ops after a failure, as a general "latch errors" principle,<br>
and obviously an VSL should be emitted that tells where things<br>
went haywire, in particular which workspace did so.<br>
<br>
Any ideas and insights are most welcome...<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20<br>
phk@FreeBSD.ORG | TCP/IP since RFC 956<br>
FreeBSD committer | BSD since 4.3-tahoe<br>
Never attribute to malice what can adequately be explained by incompetence.<br>
<br>
_______________________________________________<br>
varnish-dev mailing list<br>
<a href="mailto:varnish-dev@varnish-cache.org">varnish-dev@varnish-cache.org</a><br>
<a href="https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev" target="_blank">https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><table border="0" cellpadding="0" cellspacing="0" style="font-size:12px;line-height:1.5em;font-family:'Helvetica Neue',Arial,sans-serif;color:rgb(102,102,102);width:550px;border-top-width:1px;border-top-style:solid;border-top-color:rgb(238,238,238);border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);margin-top:20px;padding-top:5px;padding-bottom:5px">
<tbody><tr><td width="100"><a href="http://varnish-software.com" target="_blank"><img src="http://www.varnish-software.com/static/media/logo-email.png"></a><span></span><span></span></td><td><strong style="font-size:14px;color:rgb(34,34,34)">Martin Blix Grydeland</strong><br>
Senior Developer | Varnish Software AS<br>Cell: +47 21 98 92 60<br><span style="font-weight:bold">We Make Websites Fly!</span></td></tr></tbody></table></div>
</div>