Hi guys, On Thu, Mar 16, 2017 at 01:03:24AM +0100, Cyril Bonté wrote: > Hi Bryan, > > Le 16/03/2017 à 00:52, Bryan Talbot a écrit : > > > > > On Mar 15, 2017, at Mar 15, 4:44 PM, Cyril Bonté <[email protected]> > > > wrote: > > > > > > Several use cases may accept to abruptly close the connections when the > > > instance is stopping instead of waiting for timeouts to happen. > > > This option allows to specify a grace period which defines the maximum > > > time to spend to perform a soft-stop (occuring when SIGUSR1 is > > > received). > > > > > > With this global option defined in the configuration, once all > > > connections are > > > closed or the grace time is reached, the instance will quit. > > > > > > Most of the other settings for time-limits include the word "timeout". > > Maybe "timeout grace", "timeout shutdown", "timeout exit" or something is > > more consistent with other configuration options? > > Thanks for raising that point. The choice was intended and may be subject to > discussion. > > timeout keywords are (most of them, except maybe "timeout mail") defined in > defaults/frontend/backend/listen sections, whereas this one is in the global > one. I wanted to clearly differentiate that timeout to prevent some > misconfigurations. > > But I'm definitely not closed to add a "timeout" prefix. Also, I was not > very decided about the "grace" name but I didn't spend a lot of time to > write the patch (hence the [RFC] tag ;-)). You suggested "timeout shutdown", > this one may be a better choice, indeed.
In my opinion it's irrelevant to the section, but to the role. It's not a timeout but a grace time. We do already have "grace" in frontends for a similar purpose. In fact in my opinion a timeout is very different in that it's a maximum time waiting for an event to appear. Here we're not waiting for an event, we offer a grace time after the event (the reload signal). So in my opinion your choice of "grace" is perfectly suited here. Willy
