Re: Timeouts and other time-related granularity
On Wed, Jun 21, 2017 at 10:19 AM, Jim Jagielski wrote: > It would be useful to mark those directives supporting the "extended > time format" as such, but we don't have that format documented > anyplace... > > As someone who has limited docs-sense, what is the best way > to do that. Should we create some entry somewhere in our manual > that specifies that format and then, in the directive's syntax > field, link to that format? I would suggest writing it up once in http://httpd.apache.org/docs/2.4/mod/directive-dict.html then appending a brief paragraph to each directive that uses it w/ a prominent link. -- Eric Covener [email protected]
Re: Timeouts and other time-related granularity
Recommendations on how to do it better welcomed!
Re: Timeouts and other time-related granularity
It would be useful to mark those directives supporting the "extended time format" as such, but we don't have that format documented anyplace... As someone who has limited docs-sense, what is the best way to do that. Should we create some entry somewhere in our manual that specifies that format and then, in the directive's syntax field, link to that format?
Re: Timeouts and other time-related granularity
Last I checked, these already are. > On Jun 21, 2017, at 9:36 AM, Stefan Eissing > wrote: > > s->timeout > s->keep_alive_timeout > > ? > >> Am 21.06.2017 um 15:34 schrieb Jim Jagielski : >> >> I've started making some of the more obvious changes to >> support sub-single-second values for various modules... 1st >> was the watchdog and hcheck modules. >> >> It does seem like "everyplace" we have timeouts, we should take >> full advantage of the finer granularity we store anyway. Looking >> at reqtimeout and that seems ripe as well. But that seems to >> require some struct field changes, so I might hold off and >> look for lower hanging fruit. >
Re: Timeouts and other time-related granularity
s->timeout s->keep_alive_timeout ? > Am 21.06.2017 um 15:34 schrieb Jim Jagielski : > > I've started making some of the more obvious changes to > support sub-single-second values for various modules... 1st > was the watchdog and hcheck modules. > > It does seem like "everyplace" we have timeouts, we should take > full advantage of the finer granularity we store anyway. Looking > at reqtimeout and that seems ripe as well. But that seems to > require some struct field changes, so I might hold off and > look for lower hanging fruit.
Re: Timeouts and other time-related granularity
I've started making some of the more obvious changes to support sub-single-second values for various modules... 1st was the watchdog and hcheck modules. It does seem like "everyplace" we have timeouts, we should take full advantage of the finer granularity we store anyway. Looking at reqtimeout and that seems ripe as well. But that seems to require some struct field changes, so I might hold off and look for lower hanging fruit.
Re: Timeouts and other time-related granularity
I live and learn - hopefully. > Am 20.06.2017 um 15:32 schrieb Plüm, Rüdiger, Vodafone Group > : > > > >> -Ursprüngliche Nachricht- >> Von: Stefan Eissing [mailto:[email protected]] >> Gesendet: Dienstag, 20. Juni 2017 15:13 >> An: [email protected] >> Betreff: Re: Timeouts and other time-related granularity >> >> >>> Am 20.06.2017 um 14:56 schrieb Jim Jagielski : >>> >>> Most of our time-related directives accept seconds as their >>> parameters, but I'm thinking that allowing milliseconds is >>> likely a better option... From what I can see, most of what >>> would be interesting/useful to change are stored as interval/apr_time >>> anyway, so there would be no real API/struct changes required. >>> >>> Thoughts? Comments? >> >> +1 >> >> I would suggest a common duration syntax for better readability and a >> common conversion util function. We can stick to seconds if it is >> just a number, but allow fractions for millis etc. So >> >> "1" is 1 second "0.001" is one millisecond, as is "1ms". >> "1.5m" is 90 seconds, as is "1:30m" >> "1:15h" is 75 minutes >> "2:20:33.1h" is 140 minutes, 33 seconds and 100ms. >> "1:60h" is invalid, as is "1:00:00m" and "1:00:00:00" etc. > > We already have such a similar function used in various places of the config: > > /** > * Parse a given timeout parameter string into an apr_interval_time_t value. > * The unit of the time interval is given as postfix string to the numeric > * string. Currently the following units are understood: > * > * ms: milliseconds > * s : seconds > * mi[n] : minutes > * h : hours > * > * If no unit is contained in the given timeout parameter the default_time_unit > * will be used instead. > * @param timeout_parameter The string containing the timeout parameter. > * @param timeout The timeout value to be returned. > * @param default_time_unit The default time unit to use if none is specified > * in timeout_parameter. > * @return Status value indicating whether the parsing was successful or not. > */ > AP_DECLARE(apr_status_t) ap_timeout_parameter_parse( > const char *timeout_parameter, > apr_interval_time_t *timeout, > const char *default_time_unit); > > Regards > > Rüdiger
Re: Timeouts and other time-related granularity
We already have a format which is used by a few directives via ap_timeout_parameter_parse() If desired, we could extend that for the fractional stuff. > On Jun 20, 2017, at 9:12 AM, Stefan Eissing > wrote: > > >> Am 20.06.2017 um 14:56 schrieb Jim Jagielski : >> >> Most of our time-related directives accept seconds as their >> parameters, but I'm thinking that allowing milliseconds is >> likely a better option... From what I can see, most of what >> would be interesting/useful to change are stored as interval/apr_time >> anyway, so there would be no real API/struct changes required. >> >> Thoughts? Comments? > > +1 > > I would suggest a common duration syntax for better readability and a > common conversion util function. We can stick to seconds if it is > just a number, but allow fractions for millis etc. So > > "1" is 1 second "0.001" is one millisecond, as is "1ms". > "1.5m" is 90 seconds, as is "1:30m" > "1:15h" is 75 minutes > "2:20:33.1h" is 140 minutes, 33 seconds and 100ms. > "1:60h" is invalid, as is "1:00:00m" and "1:00:00:00" etc. >
RE: Timeouts and other time-related granularity
> "2:20:33.1h" is 140 minutes, 33 seconds and 100ms. This one seems very backwards to me, as leading zeros could change the meaning. Ex. 0:1:15h vs 1:15h. If allowing combination units like that (personally, it seems overkill), I think it would be much safer to require an explicit specification as 'hms', 'ms', etc. which must match the delimiter count, or to just use the least significant unit as in '1:30:15.345s'. Rick Houser Web Administration > -Original Message- > From: Stefan Eissing [mailto:[email protected]] > Sent: Tuesday, June 20, 2017 09:13 > To: [email protected] > Subject: Re: Timeouts and other time-related granularity > > > > Am 20.06.2017 um 14:56 schrieb Jim Jagielski : > > > > Most of our time-related directives accept seconds as their > > parameters, but I'm thinking that allowing milliseconds is > > likely a better option... From what I can see, most of what > > would be interesting/useful to change are stored as interval/apr_time > > anyway, so there would be no real API/struct changes required. > > > > Thoughts? Comments? > > +1 > > I would suggest a common duration syntax for better readability and a > common conversion util function. We can stick to seconds if it is > just a number, but allow fractions for millis etc. So > > "1" is 1 second "0.001" is one millisecond, as is "1ms". > "1.5m" is 90 seconds, as is "1:30m" > "1:15h" is 75 minutes > "2:20:33.1h" is 140 minutes, 33 seconds and 100ms. > "1:60h" is invalid, as is "1:00:00m" and "1:00:00:00" etc.
Re: Timeouts and other time-related granularity
> Am 20.06.2017 um 14:56 schrieb Jim Jagielski : > > Most of our time-related directives accept seconds as their > parameters, but I'm thinking that allowing milliseconds is > likely a better option... From what I can see, most of what > would be interesting/useful to change are stored as interval/apr_time > anyway, so there would be no real API/struct changes required. > > Thoughts? Comments? +1 I would suggest a common duration syntax for better readability and a common conversion util function. We can stick to seconds if it is just a number, but allow fractions for millis etc. So "1" is 1 second "0.001" is one millisecond, as is "1ms". "1.5m" is 90 seconds, as is "1:30m" "1:15h" is 75 minutes "2:20:33.1h" is 140 minutes, 33 seconds and 100ms. "1:60h" is invalid, as is "1:00:00m" and "1:00:00:00" etc.
