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 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 service now has a private std::mutex that is used for
synchronization.
Renamed the vector of services to use snake_case.
Use lock guards with mutexes to make usage easier and safer. This makes
the code smaller as well as slightly easier to read.
The service now uses a std::vector<SFilterDef> to store the filters it
uses. Most internal parts deal with the SFilterDef but debugcmd.cc still
moves raw pointers around (needs to be changed).
The signal handler no longer acquires the service list lock which removes
a number of deadlock possibilities from the shutdown process. Instead, a
global shutdown flag is set that serves the same purpose as the individual
service shutdown flags did.
Converted the internal service header to a C++ header and moved all
functions there that are for internal use only.
Added the new Service type that inherits the SERVICE struct. This is to
distinct the opaque external C interface from the C++ internals.
When a session is closed, it releases a reference on the service and
checks if it was the last session for a destroyed service. The state of
the service was loaded after the reference count was decremented. This
behavior introduced a race condition where it was possible for a service
to be freed twice, first by the thread that marked the service as
destroyed and again by the last session for that service. By always
loading the service state before decrementing the reference count, we
avoid this race condition.
Currently, the memory ordering used for the reference counting is too
strict and could be relaxed. By default, all atomic operations use
sequentially consistent memory ordering. This guarantees correct behavior
but imposes a performance penalty. Incrementing the reference counts could
be done with a relaxed memory order as long as as we know the reference
we're incrementing is valid. Releasing a reference must use an
acquire-release order to guarantee the read-modify-write operation is
successful.
Services can now be destroyed if they have no active listeners and they
are not linked to servers. When these conditions are met, the service will
be destroyed when the last session for the service is closed.
The closing of a service will close all listeners that were once assigned
to the service. This allows closing of the ports at runtime which
previously was done only on shutdown.
Exposed the command through the REST API but not through MaxAdmin as it is
deprecated.
Relaced router_options with configuration parameters in the createInstance
router entry point. The same needs to be done for the filter API as barely
any filters use the feature.
Some routers (binlogrouter) still support router_options but using it is
deprecated. This had to be done as their use wasn't deprecated in 2.2.
It is now impossible to create two listeners for a service that
would listen on the same port/socket (as before), but the error
message is now sensible and provides detailed information to the
user.
Now the users will be reloaded at most once during each
USERS_REFRESH_TIME period. Earlier they could be reloaded at
at most USERS_REFRESH_MAX_PER_TIME times, which in practice meant
that with repeated unauthorized login attempts they were reloaded
N times in rapid succession, without the situation being likely to
change in between.
The error regarding the refresh rate having been exceeded
error: [RWSplit] Refresh rate limit exceeded ...
has been turned into a warning. Further, the warning will be
logged at most once per refresh period that currently is 30s.
All modules now have an 8-bit range for capability flags. Currently only
the client side authenticator and protocol capability bits are loaded due
to the fact that backend versions of these modules don't relate to a
particular service.
Only used in conjunction with queued connections, which are not
enabled anyway. Once that comes on the table again, better to use
some standard data structures.
Only the protocol, port and address of the listener were used to check if
a listener exists. The check should also use the name of the listener to
be sure that each name is unique.
Expanded tests to check that the creation of duplicate listeners is
detected. Did minor improvements to related test code.
The listeners are now a proper sub-resource of the service resource. This
means that it acts like a normal resource and can be queried both as a
collection of resources and as an individual resource.
That allows the version to be updated and read atomically. If
major/minor/patch are stored as separate variables, you can get an
inconsistent set. Now it may be out of date by the time it is used,
but it will never be internally inconsistent.
The behaviour of the query classifier needs to change depending
on the version of the servers of a service. With this function
"some" version of the service can be obtained.
The listeners under the /services/:service/listeners collection are now
fully JSON API compliant resources.
The listeners could also be exposed as a /listeners collection to easily
group all listener type resources in one place. This approach does has
some semantical and practical problems, namely the fact that each listener
has a many-to-one relationship with its service and listeners by
themselves can't exist alone.
The `user`, `password`, `version_string` and `weightby` values should be
allocated as a part of the service structure. This allows them to be
modified at runtime without having to worry about memory allocation
problems.
Although this removes the problem of reallocation, it still does not make
the updating of the strings thread-safe. This can cause invalid values to
be read from the service strings.
The relationships from servers to services and monitors and filters to
services were not implemented. Now each server lists the services and
monitors that use it and each filter lists the services that use the
filter.
This enables the creation of a server and linking of that server to
services and monitors in one atomic operation.
When a resource has a relation to another resource, it should be expressed
as a working link to the resource. By passing the hostname of the server
to the functions, we are able to generate working relation links.
Both the filters and services can be queried via the REST API now that
these resources can be expressed in JSON format.
As with the other resources, these directly call the functions that
generate the data. This will be done via the inter-thread messaging system
once it's in place.
If a server points to a local MaxScale listener, the permission checks for
that server are skipped. This allows permission checks to be used with a
mix of external servers and internal services.
The authenticators should have a similar way to print diagnostic
information as filter and routers do. This allows the authenticators to
print the users in their own format.
In the future, all the diagnostic entry points should be changed so that
they return a structure that contains the information in a standard
form. This information can then be formatted in different ways by other
modules.
