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.
Moved some typedefs to router.h and server.h, changed a few
constants to these enums. Renamed some types in config.h to
remove "Gateway".
There are still some functions in the public header which are
only used in core, but they seem to fit the theme of public functions
so were not moved.
When the listeners were created twice, MaxScale would crash when the users
were loaded. This is caused by the fact that the DCB for the listener is
NULL for failed listeners.
Adding a server to multiple monitors is forbidden. This should be detected
and reported to the end user.
The information provided by the config_runtime system to the client isn't
as detailed as it could be. Some sort of an error message stack should be
added so that client facing interfaces could properly report the reason
for the failure. Currently the only way to detect the reason of the
failure is to parse the log files.
The service header in include/maxscale/ contains the public part of the
service API. These functions can be safely used by the modules.
The internal header located in service/core/maxscale/ is used by the core
to initialize MaxScale at startup or to provide other services in a more
controlled way (the config_runtime, for example).
The listeners aren't really destroyed and are only stopped. Further
changes are required so that they won't be started again once they have
been destroyed.
The created listeners are now stored to disk like created servers
are. This allows them to be used even after a restart.
Currently, the listeners cannot be deleted and need to be manually
removed.
The config_runtime.h header contains functions that can be used to
manipulate the running configuration. Currently the header contains the
function to create, add, remove and destroy servers.
When a service is added or removed from a service, a supplementary
configuration file is created. This allows MaxScale to survive restars and
unexpected downtime even if runtime changes to the servers of a service
have been made.
With these changes, it is possible to start MaxScale without any servers,
create servers, add the created servers to services and monitors and
restart Maxscale without losing the runtime configuration changes.
The checks for the server active status are now hidden behind a
macro. This allows for the conditions of the activity to change without
having to alter the code that uses it.
