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.
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.
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.
Since the settings are now protected fields, all related functions were
moved inside the monitor class. mon_ping_or_connect_to_db() is now a method
of MXS_MONITORED_SERVER. The connection settings class is defined inside the
server since that is the class actually using the settings.
The class MonitorManager contains monitor-related functions that should not
be called from modules. MonitorManager can access private fields and methods
of the monitor.
MaxScale server objects are now created for all Clustrix nodes.
Currently the name is "Clustrix-Server-N" where N is the number
of the node.
The server is created using runtime_create_server() that has been
modified so that it optionally will not persist the created server.
That is probably just a temporary solution as a monitor should not
need to include .../core/internal-stuff.
All global parameters are now handled by the runtime configuration
modification code. The parameters that are trivial to update can now be
updated at runtime. All other global parameters cause a new error message
to be returned stating that the parameter in question cannot be modified
at runtime.
Also updated the list of modifiable parameters in MaxCtrl. This list
should not be stored in MaxCtrl and should be created by MaxScale at
runtime.
When a listener was created at runtime but it failed to start, it would
not be automatically removed from the system. This caused the MaxCtrl
cluster sync test to fail.
Replaced the DCB with a single file descriptor that the listener listens
on and which is added to all of the workers. The Listener also extends the
MXB_POLL_DATA which allows it to handle epoll events.
Moved the code that creates the listening socket into listener.cc where it
belongs and did a minor cleanup of it.
By storing the reference in the DCB, the two-way dependency between the
listeners and services is severed. Now the services have no direct link to
listeners and after the destruction of a listener it will be freed once
all connections through it have closed.
Due to the fact that a listener itself has a DCB that must point to a
valid listener, a self-reference is stored in the listener DCB. This is
extremely confusing and is only here to keep the code functional until the
DCB part of the listener can be factored out.
By storing a shared pointer to the listeners in the services, they will be
available as long as the service using them exists. This enables clean
destruction of listeners that still have open sessions.
The listener creation code now separately creates the listener and links
it to the service. Also replaced relevant parts of the related code with
the listener implemented versions of it.
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.
If a listener is defined in a static configuration file, it can now be
destroyed at runtime. If MaxScale is restarted, the listener will be
created again unless the configuration file is modified.
