Earlier, by default, the error and message logfiles were written to
the filesystem and trace and debug logfiles to shared memory. Now,
with just one log-file the default must be the file-system. However,
if info and debug messages are logged, then the filesystem will
become a bottle-neck.
A reasonable approach is then as follows (in the config file)
syslog=true
maxlog=false
log_to_shm=true
With this set, the maxlog file will be created to shared memory, but
nothing will be written to it, since it is disabled. However, if there
is a need to investigate something, then a dba can from maxadmin turn
on maxlog logging and also enable info and debug messages. That is, it
will be possible to enable debugging output without restarting maxscale.
Incidentally, the way the config file and command line arguments are
handled should be rewritten. Currently, it is a mess.
There were some variance regarding the way the MaxScale log (i.e.
the file log) was called; "maxlog" in configuration file and
"maxscalelog" at the command line and maxadmin interface. Now it
is uniformly referred to as "maxlog" in the configuration file, at
the command line, from maxadmin and in the code.
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.
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.
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.
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.
Use of skygw_log_write() in ss_dassert and ss_info_dassert replaced
with the use of MXS_ERROR(). In addition, ss_dassert and ss_info_dassert
are now expressions that require a trailing ;.
The log message was labeled as a warning instead of an error and finding out
the real reason why MaxScale didn't start when a filter wasn't found was difficult.
When a filter module is not found or the instance creation fails, this is considered
a fatal error and MaxScale will not start. If a failure occurs when the configuration
is being reloaded, the service will not use filters and an error will be logged.
The bundled PCRE2 library will be built as a separate target and configuring
CMake no longer builds it. Instead, it will only be built when it is out of date.
This requires all targets to declare that they depend on the pcre2 target in
order for it to be built.
Previously filter instances were created when the first session was made. This
caused filter configuration errors to be noticed only after MaxScale was successfully
started. Now filters are loaded and the instance is created when a service applies its filters.
LOGIF and skygw_write_log removed from server/core/*.c and
replaced with calls to MXS_(ERROR|WARNING|NOTICE|INFO|DEBUG).
This is a mechanism change, no updating of the actual message
has been performed.
Currently this causes a very small performance hit, since the
check whether the priority is enabled or not is performed in
the function that is called and not before the function is called.
Once all LOGIFs and skygw_write_logs have been replaced, the
behaviour will be altered back to what it was.
