The class MonitorManager contains monitor-related functions that should not
be called from modules. MonitorManager can access private fields and methods
of the monitor.
The functions stores the current server status to the monitored
server's mon_prev_status and pending_status fields.
To be used at the start of the monitor loop, before the pending
status fields are updated.
Most of the ones still remaining outside are special cases.
Also, removed locking from status manipulation functions as it
has not been required for quite some time.
By exposing a (currently undocumented) debug endpoint that lets one
monitor interval pass, we make the reuse of the monitor waiting
functionality a lot easier. With it, when MaxScale is started by the test
framework it knows that at least one monitor interval will have passed for
all monitors and that the system is ready to accept queries.
This is currently disallowed for the server parameter, as the value could be
read/written concurrently. The monitor parameter can be changed since the
monitor is stopped during write.
Replaced SPINLOCK with std::mutex where possible, leaving out the more
complex cases. The big offenders remaining are the binlogrouter and the
gateway.cc OpenSSL locks.
See script directory for method. The script to run in the top level
MaxScale directory is called maxscale-uncrustify.sh, which uses
another script, list-src, from the same directory (so you need to set
your PATH). The uncrustify version was 0.66.
No longer depends on monitor events as the other operations do not
either. The active_event/new_event detection was removed, as these
only protect against a rare situation. A similar feature which
protects all the cluster modifications will be implemented later.
The master server of a monitor can now be extracted with the
mon_get_external_master function. It uses the REST API to find a master
server in the set of servers monitored by a monitor.
Services, monitors and filters all use the parameters for object
serialization. This means that when the object is created, the module
parameter must be in the parameter list.
The services, monitors and filters now construct the JSON format
parameters from the configuration parameters. This reduces the need for
the amount of explicit operations and makes adding new parameters easier.
