Backported the minimal set of changes required to build 2.1 with GCC
8. The format-truncation and format-overflow warnings are disabled instead
of fixed in 2.1 to remove duplication of effort that was already done in
2.2 (the commit doesn't cherry-pick cleanly).
The two-part shutdown procedure for the housekeeper was not needed and
caused problems if SIGINT wasn't raised. Since the main thread returns to
the main function, a single shutdown function is all that the housekeeper
needs to function.
Moved all the shutdown related code into Housekeeper::stop to remove the
waiting for the thread in the destructor.
Worker is now the base class of all workers. It has a message
queue and can be run in a thread of its own, or in the calling
thread. Worker can not be used as such, but a concrete worker
class must be derived from it. Currently there is only one
concrete class RoutingWorker.
There is some overlapping in functionality between Worker and
RoutingWorker, as there is e.g. a need for broadcasting a
message to all routing workers, but not to other workers.
Currently other workers can not be created as the array for
holding the pointers to the workers is exactly as large as
there will be RoutingWorkers. That will be changed so that
the maximum number of threads is hardwired to some ridiculous
value such as 128. That's the first step in the path towards
a situation where the number of worker threads can be changed
at runtime.
A new class mxs::Worker will be introduced and mxs::RoutingWorker
will be inherited from that. mxs::Worker will basically only be a
thread with a message-loop.
Once available, all current non-worker threads (but the one
implicitly created by microhttpd) can be creating by inheriting
from that; in practice that means the housekeeping thread, all
monitor threads and possibly the logging thread.
The benefit of this arrangement is that there then will be a general
mechanism for cross thread communication without having to use any
shared data structures.
From a practical perspective it makes no relevant difference
whether you have to add an entry to the config file and restart
maxscale or if you have to restart maxscale and provide a specific
command line, so better to provide just either possiblity.
More important would be to provide a way for turning this feature
on and off at runtime.
With the configuration entry
dump_last_statements=[never|on_close|on_error]
you can now specify when and if to dump the last statements
of of a session.
With the configuration entry
retain_last_statements=<unsigned>
or the debug flag '--debug=retain-last-statements=<unsigned>',
MaxScale will store the specified number of last statements
for each session. By calling
session_dump_statements(session);
MaxScale will dump the last statements as NOTICE messages.
For debugging purposes.
With the flag --debug=enable-statement-logging it is now possible
to instruct MaxScale to log all SQL statements it sends to the
servers.
The format of the logged string looks like:
notice : SQL(127.0.0.1): 0, "SELECT ..."
First the fixed string "SQL", followed by the server address in
parenthesis followed by the actual return value of mysql_query(),
followed by the statement itself.
The "SQL" string makes the lines easy to grep for and having the
return value before the statement makes it easier to spot since
the length of the return value string does not wary much, but the
length of the statements do wary a lot.
According to customer reports collecting the statistics has a significant
impact on the performance. As we don't need that information we can just
as well turn off that.
Further, since maxscale-common now links to the sqlite3-library, no
module needs to do that explicitly.
The internal header directory conflicted with in-source builds causing a
build failure. This is fixed by renaming the internal header directory to
something other than maxscale.
The renaming pointed out a few problems in a couple of source files that
appeared to include internal headers when the headers were in fact public
headers.
Fixed maxctrl in-source builds by making the copying of the sources
optional.
With "--daemon" or "-n" MaxScale can now be told to run in daemon
mode, that is, it forks and the parent exits. This is the default
behaviour, but a flag to this effect is needed if the default
behaviour is changed.
MaxScale now refuses to run as root. However, it is possible to
start MaxScale as root, as long as a user to run MaxScale as is
provided as a command line argument.
It is possible to run as root by invoking MaxScale as root and
by specifying the MaxScale user to be root.
When pre-parsing the configuration file, the existence of environment
variables is only done for the [maxscale] section. For other sections
a nicer error message is obtained if the comlplaint is made when the
configuration file is actually loaded.
Mechanism for providing custom error message from the pre-parsing
function added.
With this variables set to true, if $VAR is used as a value in the
configuration file, then `$VAR` will be replaced with the value of
the environment variable VAR.
The GLIBC backtrace functionality doesn't generate file names and line
numbers in the generated stacktrace. This can to be done manually by
executing a set of system commands.
Conceptually doing non-signal-safe operations in a signal handler is very
wrong but as stacktraces are only printed when something has gone horribly
wrong, there is no real need to worry about making things worse.
As a safeguard for fatal errors while the stacktrace is being generated,
it is first dumped into the standard error output of the process. This
will function even if malloc is corrupted.
The GLIBC backtrace functionality doesn't generate file names and line
numbers in the generated stacktrace. This can to be done manually by
executing a set of system commands.
Conceptually doing non-signal-safe operations in a signal handler is very
wrong but as stacktraces are only printed when something has gone horribly
wrong, there is no real need to worry about making things worse.
As a safeguard for fatal errors while the stacktrace is being generated,
it is first dumped into the standard error output of the process. This
will function even if malloc is corrupted.
The stack traces weren't logged as the LOG_ALERT priority wasn't enabled
by default. As an alert is intended to be something that must leave a
trace somewhere, and as such, it must not be possible to disable it. For
this reason, it is acceptable to always log the message if the priority is
LOG_ALERT.
Added the -rdynamic linker flag so that all symbols are exported when
linking MaxScale.
As the stack trace is printed in a signal handler, the first attempt
should be to print the stack trace to the standard output. This way the
output is printed before an attempt to use malloc is made when it is
logged to the logfile.
The `passive` parameter can be given in the configuration file or on the
command line. It is displayed in the diagnostic output and changes to it
are persisted.
The variable itself does nothing.
