modutil_get_complete_packets was assuming that at least 3 bytes of each packet
is available. This results in an out-of-bounds read if less than 3 bytes of data
for a partial result set is available.
In blr_open_binlog the refcnt increase of file which is already
open is protected by router->fileslock. In blr_close_binlog the
decrease of the refcnt was protected by file->lock.
This lead to a situation where it was possible that a file was
closed and the file instance freed, even though it just had been
taken into use by somebody else.
This is now fixed by solely using the router->fileslock for protecting
the increase and decrease of the refcnt.
The limit_queries parsing used a bad initial value for the return value
which lead to a guaranteed failure. Other parts of the code used wrong values
for comparisons leading to sporadic parsing errors.
The mqfilter was not built by default even though it should have been. This has
been fixed but the filter is built only if librabbitmq is found. This was done
to avoid having the librabbitmq and its development headers as a hard
dependency.
The fact that the maxscale process exits only after all services have been
started means that systemd will kill the maxscale process if starting the
services takes too long. Since the user authentication data is loaded on
startup and can take up a long time, there needs to be a longer than
default timeout for systems that use systemd.
If individual servers had a weightby parameter value greater than INT_MAX * 1000
the integer used for calculation would overflow and the server would end up
having a negative weight. This would cause all connections to pile up on this
server.
The same overflow was possible for the sum of all the weightby parameter values
even if no single parameter exceeded the limit.
A large part of parse_query was parsing of the actual rule definitions. This made
the function very large and hard to understand. For this reason the definition parsing
was moved to its own function.
The earlier log file based approach for enabling and disabling
messages has now been completely replaced with the syslog priority
based approach.
Similarly as with log files before it is now possible to enable
and disable a log priority for a particular session, even though
it apparently has not been used much.
The local test-programs of the logging has got minimal attention
only to make them compile. They should get an overhaul as they did
not work before either.
Maxadmin earlier gave the impression that you could change whether
messages for different log files could be specifically enabled for
a session. In practice that was true only for trace messages as the
session id and the bitmask telling what logfiles are enabled, were
copied to thread local storage only as far as trace messages were
concered.
The code for setting that information in place is quit short and
efficient, so there is really no reason not to do that always.
This also means that it always will be possible to get your hands
on the session object if there is a need for that.
The code used in the query classifier was not compatible with 10.1 version
of MariaDB and needed to be fine tuned in order for it to work with all
supported versions of MariaDB.
In blr_slave.c under certain conditions, two locks were not released.
That was fixed in another change, and with this change a notice will be
logged if that branch is entered. That way it will be possible to find
out whether this may have been the cause of earlier lock-ups.
In blr_slave.c under certain conditions, two locks were not released.
That was fixed in another change, and with this change a notice will be
logged if that branch is entered. That way it will be possible to find
out whether this may have been the cause of earlier lock-ups.
The regular expression used when cleaning multiline configuration parameters
didn't match trailing backslash characters in pathnames. This caused them to be
added to the next line causing a possible error.
The combination of only one slave being used and the slave_selection_criteria
being LEAST_CURRENT_OPERATIONS can possibly cause a connection pileup on one
slave server. This would skew the query distribution heavily towards the first
available slave even if multiple slave were being used.
Having the maximum number of slave servers to be equal to the total amount of
available slaves allows for a more even and responsive distribution of the
query traffic.
The build files for monitors were referring to monitor_common.c which was
refactored out and combined with monitor.c. Due to this change, maxbinlogcheck
required maxscale_pcre2.c and externcmd.c.
Since localtime is not thread-safe it should not be used in multithreaded
contexts. For this reason all calls to localtime were changed to localtime_r
in code where concurrency issues were possible.
Internal tests were left unchanged because they aren't multithreaded.
Claiming that the loading of maxscale.cnf failed in case of any
error was misleading. Maxscale may not succeed in opening it,
reading it or processing it.
