Given that worker.hh was public, it made sense to make routingworker.hh
public as well. This removes the need to include private headers in
modules and allows C++ constructs to be used in C++ code when previously
only the C API was available.
The mxs::rworker_local<T> is a convenience type that provides fast read
access with thread-safe updates. It is intended to be used with data that
is read often but updated rarely e.g. configuration data for routers.
By storing the data gathere by readwritesplit inside the session, the
protocol will be aware of the state of the LOAD DATA LOCAL INFILE
execution. This prevents misinterpretation of the data which previously
led to closed connections, effectively rendering LOAD DATA LOCAL INFILE
unusable.
This change is a temporary solution to a problem that needs to be solved
at the protocol level. The changes required to implement this are too big
to add into a bug fix release.
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 maxscale_is_shutting_down function is used to detect when MaxScale
should stop. This fixes a race condition in the code where the workers has
not yet been initialized but a termination signal has been received. It
also replaces the misuse of the service_should_stop variable with a proper
function.
qc_thread_init() must now explicitly be called in every thread
and not just in other threads but the one where qc_process_init()
is called.
This change was caused by QC_INIT_SELF initialization actually
being performed in query_classifier.cc. Before this change, there
actually was a leak in the routing worker running in the main
thread, the query classification cache was created twice.
The print_log_n_stderr function used to implicitly initialize the log
manager. As this is no longer done, no logging must be done before the log
manager is initialized.
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.
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 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.
