The monitor JSON is now more closely inspected before the actual monitor
is allocated. This prevents creation of monitors without credentials which
was previously possible.
The monitor alteration was also changed to stop and start the monitor only
once instead of stopping and starting after each parameter
modification. This prevents multi-parameter updates from failing due to
monitors seeing a partial set of the new values. Currently only the
`replication_user` and `replication_password` parameters could cause this.
If a service was created at runtime, it would be in the Allocated state
until it was stopped. The serviceStart function isn't necessary from a
functional point of view (a new service cannot have listeners that need
starting) but it does set the correct state and it's the "right" thing to
do.
Monitors created via the REST API that were started and configured
successfully should also be started. This removes the extra step of
starting the monitor after creating it.
The executable name of the PID is now checked to be maxscale. This fixes
the problem where MaxScale would refuse to start if a stale PID file had a
PID of a process that's not a MaxScale process.
Enabling it will give a performance improvement and it offloads work from
the CPU. This leads to better and more complete utilization of system
resources.
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.
The test does a request and prints the responses. It is done to see that
the functionality works. Also added a timeout of 10 seconds to both the
connection and data transfer phases.
When the replication status from the external master is checked, the
pending status must be used. This makes sure that the SlaveStatusArray and
the server state are sync.
Also extended the message that was logged when the external master was
lost. By adding the network address there, it makes it easier to see where
the server was replicating from if only the log file is available.
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.
Everything of maxbase can now be initialized by a call to
maxbase_init();
(from a C-program) or
maxbase::init();
from a C++-program and finalized with calls to either
maxbase_finish() or maxbase::finish(). Creating an instance
maxbase::MaxBase will take care of both operations.
The parameter validation for all module types follows roughly the same
path: first check whether it's a known parameter and then whether the
value is valid. This can be moved into common functions that removes
duplicated code.
The SSL initialization should only be attempted if `ssl_key`, `ssl_cert`
or `ssl_ca_cert` is defined. In addition to this, the SSL parameters
requirements for servers and listeners are different: servers require only
`ssl_ca_cert` but listeners require all three.
The config and JSON serialization of servers is now from the
parameters. As the server's use a different parameter type, a temporary
adapter was required. Eventually, a lock-free and globally safe way to
"disable" parameters is needed.
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.
The runtime modification of servers, services and monitors now validates
the parameters before starting the update process. This guarantees that
the set of parameters is valid before it is processed.
After the validation, the parameters are now also stored in the list of
configuration parameters. This will simplify the serialization process by
removing the need to explicitly serialize all common object parameters.
Putting the file descriptor first keeps it in line with dprintf.
Making the parameter set an initializer list allows matching against
multiple sets of parameters in one function call. This will compact the
parameter serialization by using the same code for the common service
parameters and the module parameters.
