The /maxscale/ resource now supports PUT requests which modify core
parameters. As not all parameters can be changed at runtime, only
modifications to parameters that support runtime configuration are
allowed.
A set of the core MaxScale parameters can now be altered at runtime. This
set consists of the authentication timeouts and the admin interface
authentication. Other parameters either can't be modified due to internal
limitations or aren't sensible to modify at runtime.
The /users/ resource shows all user accounts that can be used with
MaxScale. This resource is further split into two resource collections,
/users/inet and /users/unix, which contain the network users and Linux
accounts respectively.
The REST API now uses the same users as MaxAdmin network interface. This
allows them to be created with MaxAdmin.
The next step is to add user creation to the REST API.
The runtime error buffer is now a thread-local buffer. This fixes the
build failure on older systems where the compiler doesn't allow
thread-local non-POD objects to be created.
Also expanded some of the JSON validation functions so that they provide
better errors.
The requests that send a body should define at least a `data` member.
Added a simple test that checks that bad requests are rejected. This test
should be expanded to check that the returned error body contains the
correct members.
This allows MaxScale to use the PATCH functionality that's only in the
newer versions of the library. It also removes some of the problems that
exist with older systems that don't support all of the options.
Standalone events in transaction (no COMMIT event) are now handled:
the GTID is saved to gtid_maps storage.
Transaction detection assumes there is only one query_event after GTID
event with MARIADB_FL_STANDALONE flag set.
Saving GTID components into gtid_maps storage will allow to create a
hiearchical binlog cache dir.
Empty GTID for master registration can be specified with SET
@@global.gtid_slave_pos = ‘’
The template class wraps a HashMap such that only a few operations
are allowed. Usage requires specializing a RegistryTraits class
template for each entry type.
The /maxscale/ resource now has values for most of the configuration
parameters in the [maxscale] section as well as the version, commit and
uptime information.
When a cloned DCB is created, the service pointer is not copied and it
needs to be manually set in the newSession entry point. This most likely
due to the fact that the cloned DCB always has a different service and it
is not possible to deduce it.
Another option would be to pass the target service as a parameter but the
whole DCB cloning process could use with a rewrite so any modifications
beyond the required minimum are wasteful.
The example in the epoll(7) manpage only sets the EPOLLIN event flag.
Although it is not explicitly stated that only EPOLLIN events arrive for
sockets that are listening, any other types of events should not be
relevant for listeners.
If a connection has not been fully established (i.e. authentication has
been completed) then it should not be considered as a connection pool
candidate.
