<div dir="ltr"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">What about marking the upstream servers you want to update as 'down' in their pool, reloading the configuration (HUP signal, gracefully shutting down old workers), and waiting for the links to those servers to be clear of any activity?<br></div><div class="gmail_extra"><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">​Then upgrade and reintegrate updated servers in the pool (while disabling others/old version, if needed).​<br><br></div><div class="gmail_default" style="font-size:small;color:rgb(51,51,153)">This kind of manual rotation is trivial.<br></div><div><div class="gmail_signature" data-smartmail="gmail_signature"><font size="1"><span style="color:rgb(102,102,102)">---<br></span><b><span style="color:rgb(102,102,102)">B. R.</span></b><span style="color:rgb(102,102,102)"></span></font></div></div>
<br><div class="gmail_quote">On Thu, Aug 25, 2016 at 3:44 PM, Emiel Mols <span dir="ltr"><<a href="mailto:emiel.mols@gmail.com" target="_blank">emiel.mols@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">Hey,</p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><span style="line-height:1.5">I've been haunted by this for quite some time, seen it in different deployments, and think might make for some good ol' mailing list discussion.</span></p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">When</p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><span style="line-height:1.5">- using keep-alive connections to a backend service (eg php, rails, python)<br>- this backend needs to be updatable (it is not okay to have lingering workers for hours or days)<br>- requests are often not idem-potent (can't repeat them)</span></p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">current deployments need to close the kept-alive connection from the backend-side, always opening up a race condition where nginx has just sent a request and the connection gets closed. This leaves nginx in limbo not knowing if the request has been executed and can be repeated.</p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><span style="line-height:1.5">When using keep-alive connections the only reliable way of closing them is from the client-side (in this case: nginx). I would therefor expect either</span><br></p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><span style="line-height:1.5">- a feature to signal nginx to close all connections to the backend after having deployed new backend code. </span></p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><span style="line-height:1.5">- an upstream keepAliveIdleTimeout config value that guarantees that kept-alive connections are not left lingering indefinitely long. If nginx guarantees it closes idle connections after 5 seconds, we can be sure that 5s+max_request_time after a new backend is deployed all old workers are gone.</span></p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><span style="line-height:1.5">- (variant on the previous) support for a http header from the backend to indicate such a timeout value. It's funny that this header kind-of already exists in the spec <</span><a href="https://tools.ietf.org/id/draft-thomson-hybi-http-timeout-01.html#keep-alive" target="_blank">https://tools.ietf.org/id/<wbr>draft-thomson-hybi-http-<wbr>timeout-01.html#keep-alive</a>><span style="line-height:1.5">, but in practice is implemented by no-one.</span></p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">The 2nd and/or 3rd options seem most elegant to me. I wouldn't mind implementing myself if someone versed in the architecture would give some pointers.</p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><span style="line-height:1.5">Best regards,</span><br></p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">- Emiel</p>BTW: a similar issue should exist between browsers and web servers. Since latency is a lot higher on these links, I can only assume it to happen a lot.</div>
<br>______________________________<wbr>_________________<br>
nginx mailing list<br>
<a href="mailto:nginx@nginx.org">nginx@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx</a><br></blockquote></div><br></div></div>