<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
</div>
<span>On Mo, Mar 23, 2020 at 10:00 AM Dridi Boukelmoune <dridi at varni.sh> wrote:<br>
</span>
<div>> <br>
</div>
<div>> For starters, there currently is no way to know for sure that you<br>
</div>
<div>> entered vcl_synth because of a return(abandon) transition. There are<br>
</div>
<div>> plans to make it possible, but currently you can do that with<br>
</div>
<div>> confidence lower than 100%.<br>
</div>
<div><br>
</div>
<div>I see. I actually had a feeling about that, since I didn't see an obvious way to pass that kind of information into vcl_synth when triggered by an abandon.<br>
</div>
<div><br>
</div>
<div>Although, just having a general rule to restart 500-requests there, regardless of what caused it, is not really that bad anyway.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>> A problem with the restart logic is the race it opens since you now<br>
</div>
<div>> have two lookups, but overall, that's the kind of convoluted VCL that<br>
</div>
<div>> should work. The devil might be in the details.<br>
</div>
<div><br>
</div>
<div>Could you describe this race condition that you mean can happen? What could the worst case scenario be? If it is just a guru meditation for this single request, and it happens very rarely, then that is something I can live with. If it is something that
can cause Varnish to crash or hang, then it is not something I can live with :)<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>> In this case you might want to combine your VCL restart logic with<br>
</div>
<div>> vmod_saintmode.<br>
</div>
<div><br>
</div>
<div>Yes, I have already heard some things about this vmod. I will definitely look into it. Thanks.<br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>> And you might solve this problem with vmod_xkey!<br>
</div>
<div><br>
</div>
<div>We actually already use this vmod. But like I said, it doesn't solve the problem with new content that effects existing pages. Several pages might for example include information about the latest objects created in the system. If one of these pages were
loaded and cached at time T1, and then at T2 a new object O2 was created, an "xkey purge" with the key "O2" will have no effect since that page was not associated with the "O2" key at time T1, because O2 didn't even exist then.<br>
</div>
<div><br>
</div>
<div>And since there is no way to know beforehand which these pages are, the only bullet proof way I can see of handling this is to purge all pages* any time any content is updated.<br>
</div>
<div><br>
</div>
<span>* or at least a large subset of all pages, since the vast majority might include something related to newly created objects</span>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText"><br>
</div>
</span></font></div>
</body>
</html>