This fixes the test failures that stem from users being created right
after maxscale has started. This also should make startups a bit smoother
now that the default value of users_refresh_time has been fixed.
Fetching the users may potentially take longer than the watchdog
timeout. To ensure that MaxScale is not killed by systemd, we must
ensure that the notifications are generated also when MaxScale
synchronously is fetching the users.
The servers with a zero weight would be always used over ones that have a
weight. This means that the behavior was inverted and caused the
mxs2054_hybrid_cluster test to fail in 2.3.
Also fixed a typo in the deprecation message.
Even though directly closing the socket is not very neat in the
architectural sense of things, it allows the best of both worlds: the
socket is instantly closed and is open for reuse while the listener struct
is still available as a reference.
This change needs to be revised when the listeners are refactored into
separate objects.
Updated documentation to reflect the change in behavior.
See script directory for method. The script to run in the top level
MaxScale directory is called maxscale-uncrustify.sh, which uses
another script, list-src, from the same directory (so you need to set
your PATH). The uncrustify version was 0.66.
The math becomes simpler when the weight is inverted, i.e. a simple multiplication
to get the (inverse) score. Inverse weights are normalized to the range [0..1] where a lower
number is a higher weight,
The enum select_criteria_t is used to provide a std::function that takes the backends
as vector (rather than the prior pairwise compares) and returns the best backend.
Given that worker.hh was public, it made sense to make routingworker.hh
public as well. This removes the need to include private headers in
modules and allows C++ constructs to be used in C++ code when previously
only the C API was available.
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.
Services, monitors and filters all use the parameters for object
serialization. This means that when the object is created, the module
parameter must be in the parameter list.
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 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).
If a service has filters, they must first be removed before the service
can be destroyed. This is not a functional requirement but it keeps the
behavior consistent so that the relationships of a service must be empty
before it is destroyed.
If a listener was created at runtime and at some point it fails (e.g. the
port is already taken), the listener would be removed from the service. In
2.2, the removal of the listeners simply marked the listener as
inactive. In 2.3, the functions were combined so that the listener is
marked as inactive and removed from the workers. The fact that the
listener had a NULL DCB at that point caused the crash.
The correct thing to do is to not remove the listener from the service and
to mark the listener as inactive in the close_port helper function. The
listener will be freed once the service is destroyed.
The service capabilities were not set for filters as the name overlapped
with a local variable. The variable name was fixed but the actual use of
it was not.
As the filters are only passed as a pipe separated list when the
configuration is being processed, there's no need to have the interface
conform to that. Passing a list of filter names makes it more flexible and
will make it's use in the runtime configuration easier.
The service now generates the configuration file that represents the
serialized form of it. Also removed the unused service_serialize_servers
function.
The services will now store a local copy of the filter lists in the worker
local data associated with the service. This removes the instance level
lock and removes the performance penalty that was previously imposed by
it.
The only remaining performance "regression" compared to 2.2 is the extra
two atomic operations per filter that a session does when it is being
created. This is quite hard to get rid of without significant amounts code
and will hopefully be just a drop in the ocean.
The most relevant string variables of a service are now duplicated as C++
strings. This should ease the eventual transition to a fully C++ internal
representation of the service. The array of refresh rates was also wrapped
inside a std::vector to remove the need to manually manage memory.
Separated the SERVICE_USER struct into its individual components as there
was no real need to have them inside a struct.
The filters can now be altered at runtime. Currently, the filter usage
uses a service level lock. The next is to allocate a per-service key to
the worker local data and use that to orchestrate the storage of the
filter lists.
