Introduce duration suffixes (MXS-2327)

[MXS-2253] Different grains of time in maxscale.cnf Created: 2019-01-09  Updated: 2019-04-11  Resolved: 2019-02-14

Status: Closed
Project: MariaDB MaxScale
Component/s: Core
Affects Version/s: 2.3.2
Fix Version/s: 2.4.0

Type: Sub-Task Priority: Minor
Reporter: Austin Rutherford (Inactive) Assignee: Johan Wikman
Resolution: Fixed Votes: 0
Labels: None

Sprint: MXS-SPRINT-75, MXS-SPRINT-76, MXS-SPRINT-77, MXS-SPRINT-78, MXS-SPRINT-79, MXS-SPRINT-80, MXS-SPRINT-81

 Description   

The maxscale.cnf file has some fields that use seconds and some that use milliseconds. Customers can get these different grains to be confusing. All timeouts/fields with time should either be milliseconds or seconds.

Tactically, we could put comments after the field in the default .cnf file.

monitor_interval=2500 # this field is in milliseconds



 Comments   
Comment by markus makela [ 2019-01-10 ]

Another idea would be to add support for suffixed time types like we have for sizes:

monitor_interval=5s
monitor_interval=2000ms
monitor_interval=1m

Comment by Johan Wikman [ 2019-01-10 ]

Time suffixes is the way to go. That way it's completely unambiguous what the number means.

Comment by Austin Rutherford (Inactive) [ 2019-02-05 ]

Looks good. One item though - if they don't add a suffix they should IMO either error out or default to the same grain (seconds or milleseconds)

Comment by Johan Wikman [ 2019-02-13 ]

It's going to be like this;

  • The suffixes h, m, s and ms are introduced, using which a duration can be specified in hours, minutes, seconds or milliseconds, respectively.
  • In MaxScale 2.4, if no explicit unit is specified, a value without a unit will be interpreted the way it is interpreted now (i.e. either as seconds or milliseconds), and a warning will be logged that a unit should be provided.
  • Not providing an explicit unit is deprecated in MaxScale 2.4.
  • Not providing an explicit unit will cause an error in some version after MaxScale 2.4.
Generated at Thu Feb 08 04:12:47 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.