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.
The config and JSON serialization of servers is now from the
parameters. As the server's use a different parameter type, a temporary
adapter was required. Eventually, a lock-free and globally safe way to
"disable" parameters is needed.
The services, monitors and filters now construct the JSON format
parameters from the configuration parameters. This reduces the need for
the amount of explicit operations and makes adding new parameters easier.
The runtime modification of servers, services and monitors now validates
the parameters before starting the update process. This guarantees that
the set of parameters is valid before it is processed.
After the validation, the parameters are now also stored in the list of
configuration parameters. This will simplify the serialization process by
removing the need to explicitly serialize all common object parameters.
Putting the file descriptor first keeps it in line with dprintf.
Making the parameter set an initializer list allows matching against
multiple sets of parameters in one function call. This will compact the
parameter serialization by using the same code for the common service
parameters and the module parameters.
The atexit functions should be registered after there is a need for
them. This fixes the problem where cleanup functions were called before
the initialization for them was done. Also removed the header and footer
printint to stdout.
The semaphore is only used when Worker::start() is called to synchronize
the startup of the two threads. Also asserted that the state is what we
expected it to be.
Now that the exit handlers work correctly, the output of `maxscale
--version` no longer consists of a single line but multiple lines in both
stdout and stderr. Removing the printing to stderr guarantees that the
correct output is produced.
This guarantees that the caller of the start function will know whether
the worker is running by looking at its state.
This will prevent multiple successive stop calls to a worker which
happened when the monitors were altered via the REST API.
The current implementation of mxs_log_message() is otherwise
generic, but for the fact that the session id is automatically
injected into the message.
With this change, a mxs_log_init2() is introduced that in addition
to the existing parameters takes a function using which the context
can be provided. The implementation of mxs_log_init() now simply
calls mxs_log_init2() giving a function that provides the MaxScale
context.
This is in preparation for moving maxscale/log_manager.h to
maxbase/log.h.
The function should not be an inline function with a static variable. This
appears to cause problems on at least Debian Wheezy and is likely to cause
odd behavior on other platforms.
Also renamed the file to <maxbase/string.h> to better mirror how the
<string.h> file behaves.
The service configuration serialization now uses the helper functions from
config.hh. This fixes the failing test mxs1731_old_persisted_config and
improves the readability of persisted configuration files.
Converted parameters into booleans that were used like booleans. This
forced the removal of the automatic enabling of
localhost_match_wildcard_host but since it has been enable by default,
this change should have no practical effects.
In addition to the clarification of the persisted configurations, this
change will limit the negative side-effects of changing a configuration
value in the main configuration file after a runtime modification has been
made. If a value has not been modified at runtime, changes to it in the
main configuration will take effect.
Previously, a runtime modification prevented all further manual changes to
the configuration file. Although in theory this sounds good, in practice
this does very little to improve the situation: The only reliable way to
change a parameter after a runtime modification is to do it via the REST
API (or MaxAdmin).
The functions dump of parameters only if they differ from the
defaults. The check for equality is rather coarse but it should work as
long as all core objects use C++ types correctly e.g. integer are not used
to store boolean values (I'm looking at you, enable_root and
localhost_match_wildcard_host). The boolean type has a specialization to
convert the value to the string format used for all defaults in the core.
This also adds the missing return value checks to the dprintf calls and
reports errors if any are encountered.
