Previously, runtime monitor modifications could directly alter monitor fields,
which could leave the text-form parameters and reality out-of-sync. Also,
the configure-function was not called for the entire monitor-object, only the
module-implementation.
Now, all modifications go through the overridden configure-function, which calls the
base-class function. As most configuration changes are given in text-form, this
removes the need for specific setters. The only exceptions are the server add/remove
operations, which must modify the text-form serverlist.
Always storing runtime configuration changes prevents problems when the
change causes another parameter to change. One example of this is
transaction_replay that implicitly enables other parameters.
If a DCB was closed and a hangup event was sent to it via
dcb_hangup_foreach shortly after it was closed, the DCB would still
receive it even if it was closed. To prevent this, events must only be
delivered to DCBs if they haven't been closed.
Keeping the parser state internal to a subclass makes the code more
readable and allows the removal of most parameters. It also removes the
need to return iterator ranges from the tokenization function thus making
the Token class obsolete.
Unit testing benefits from this as well as it more closely resembles usage
in the wild as more of the code can be run without a live system.
When the SERVER_BEING_DRAINED bit is on, if the number of connections
to the server is 0, the state is reported as "Drained", otherwise as
"Being Drained".
The config parameter ordering depends on which end of the linked list the
parameters are added. The test should be re-enabled once parameter handling
has been refactored.
Added a new module parameter type to be used for parameters
that specify a duration. With the suffixes 'h', 'm', 's' and
'ms' the duration can be specified in hours, minutes, seconds
or milliseconds, respectively.
Irrespective of how the duration is specified, it is always
returned as milliseconds.
For backward compatibility, when a duration value is read it must
be specifed how a value *not* defined using a suffix should be
interpreted; as seconds or milliseconds.
value = param->get_duration(name, mxs::config::INTERPRET_AS_SECONDS);
Worker::STOPPED -> MONITOR_STATE_STOPPED
Worker::POLLING -> MONITOR_STATE_RUNNING
Worker::PROCESSING -> MONITOR_STATE_RUNNING
By defining the monitor state from the worker state there is
no risk they will ever get out of sync. And there is one thing
less to maintain.
As m_servers is a member of Monitor, it is better if the closing
of the MYSQL connections is done there, so that derived classes
do not need to remember doing that.
When the servers of a service are defined by a monitor, then
at startup all servers of the monitor should be added to relevant
services. Likewise, when a server is added to or removed from a
monitor at runtime, those changes should affect services as well.
However, whether that should happen or not depends upon the monitor.
In the case of the Clustrix monitor this should not happen as it
adds and removes servers depending on the runtime state of the
Clustrix cluster.
If the servers of a service are defined by a monitor (the config
has 'cluster=SomeMonitor'), then the addition of a server to a
a monitor should lead to that server being added to the service.
The services whose servers are defined using a monitor, will
now be populated from the monitor.
Note, no consideration has yet been given to runtime changes.
The manipulation functions are currently static so that the container can be initialized
if required. This will be fixed later.
The new functions are taken into use in monitor management.
