You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2017/06/20 12:56:49 UTC
Timeouts and other time-related granularity
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?
RE: Timeouts and other time-related granularity
Posted by "Houser, Rick" <ri...@jackson.com>.
> "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:stefan.eissing@greenbytes.de]
> Sent: Tuesday, June 20, 2017 09:13
> To: dev@httpd.apache.org
> Subject: Re: Timeouts and other time-related granularity
>
>
> > Am 20.06.2017 um 14:56 schrieb Jim Jagielski <ji...@jaguNET.com>:
> >
> > 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
Posted by Jim Jagielski <ji...@jaguNET.com>.
Last I checked, these already are.
> On Jun 21, 2017, at 9:36 AM, Stefan Eissing <st...@greenbytes.de> wrote:
>
> s->timeout
> s->keep_alive_timeout
>
> ?
>
>> Am 21.06.2017 um 15:34 schrieb Jim Jagielski <ji...@jaguNET.com>:
>>
>> 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
Posted by Stefan Eissing <st...@greenbytes.de>.
s->timeout
s->keep_alive_timeout
?
> Am 21.06.2017 um 15:34 schrieb Jim Jagielski <ji...@jaguNET.com>:
>
> 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
Posted by Eric Covener <co...@gmail.com>.
On Wed, Jun 21, 2017 at 10:19 AM, Jim Jagielski <ji...@jagunet.com> 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
covener@gmail.com
Re: Timeouts and other time-related granularity
Posted by Jim Jagielski <ji...@jaguNET.com>.
Recommendations on how to do it better welcomed!
Re: Timeouts and other time-related granularity
Posted by Jim Jagielski <ji...@jaguNET.com>.
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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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
Posted by Stefan Eissing <st...@greenbytes.de>.
I live and learn - hopefully.
> Am 20.06.2017 um 15:32 schrieb Plüm, Rüdiger, Vodafone Group <ru...@vodafone.com>:
>
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
>> Gesendet: Dienstag, 20. Juni 2017 15:13
>> An: dev@httpd.apache.org
>> Betreff: Re: Timeouts and other time-related granularity
>>
>>
>>> Am 20.06.2017 um 14:56 schrieb Jim Jagielski <ji...@jaguNET.com>:
>>>
>>> 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
AW: Timeouts and other time-related granularity
Posted by Plüm,
Rüdiger,
Vodafone Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
> Gesendet: Dienstag, 20. Juni 2017 15:13
> An: dev@httpd.apache.org
> Betreff: Re: Timeouts and other time-related granularity
>
>
> > Am 20.06.2017 um 14:56 schrieb Jim Jagielski <ji...@jaguNET.com>:
> >
> > 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
Posted by Jim Jagielski <ji...@jaguNET.com>.
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 <st...@greenbytes.de> wrote:
>
>
>> Am 20.06.2017 um 14:56 schrieb Jim Jagielski <ji...@jaguNET.com>:
>>
>> 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
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 20.06.2017 um 14:56 schrieb Jim Jagielski <ji...@jaguNET.com>:
>
> 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.