The master reconnection in the binlogrouter used the housekeeper
recursively. This is no longer supported and the delayed worker call
mechanism should be used in its stead.
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.
If a large packet is received, the stack would overflow when the username
size was determined from the packet size. The code must not assume
anything about the size of the packet being read.
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.
Reducint the time the load testing runs for seems to reduce the volume by
the same amount. Given that unit tests are good for catching obvious
mistakes, the test should still be adequate.
The recursive calls into `read` caused unnecessary slowness in the
connection phase. The actual first row should only be read when the data
is requested. This can possibly solve the false timeout errors caused by
slow sending of the first row of data.
In default case MaxScale uses ipv6 for all addresses also mapping ipv4
connections to ipv6. This caused NamedServerFilter to never match these
addresses to the ones defined in source parameter in ipv4 form.
These ipv6-mapped addresses are now transformed to ipv4 so they can be
checked against source parameter list.
Source parameter in NamedServerFilter can now contain a list of source
addresses seperated by comma. This parameter is parsed into a list of ip
addresses and checked against incoming client connections.
The current monitor detects the extra slave connection before
failover is launched, turning the entire feature off. That part of
the test has been removed.
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.
