The JSON API specification states that all resources must support direct
modification of resource relationships by providing only the definition
for a particular relationship type to a /:type/:id/relationships/:type
endpoint.
The relevant part of the JSON API specification:
http://jsonapi.org/format/#crud-updating-to-many-relationships
The total timeout for the retrying of interrupted queries can now be
configured with the `query_retry_timeout` parameter. It controls the total
timeout in seconds that the query can take.
The actual connection, read and write timeouts of the connector aren't a
good configuration value to use for abstracted queries as the time that it
takes to execute a query can be composed of both connections, reads and
writes. This is caused by the usage of MYSQL_OPT_RECONNECT that hides the
fact that the connector reconnects to the server when a query is
attempted.
The new `query_retries` parameter controls how many times an interrupted
query is retried. This retrying of interrupted queries will reduce the
rate of false positives that MaxScale monitors detect.
The `failover` and `failover_timeout` parameters are now declared as a
part of the mysqlmon module. Changed the implementation of the failover
function so that the dependencies on the monitor struct can be removed or
moved into parameters.
The failover command is simulated by executing a call to /usr/bin/echo
with all possible monitor parameters. This allows testing of the failover
mechanism without actually using the failover command.
The timestamp of the last change from passive to active is now
tracked. This, with the timestamps of the last master_down and master_up
events, allows detection of cases when MaxScale was failed over but the
failover was not done.
Currently, only a warning is logged if no new master has appeared within
90 seconds of a master_down event and MaxScale was set to active from
passive.
The last event and when the event was triggered is now shown for all
servers. The latest change from passive to active is also shown.
When the subprocess outputs a line, the message should be logged
immediately. This allows automated timestamps for the output of the
executed subprocess.
The authentication errors were not sent as the connection was closed
immediately. The reason for this was the fact that if a client request
uploaded data with bad credentials, MaxScale would not send a response if
the connection was kept open. Closing the socket solved the hang but
caused confusing errors on the client side.
The libmicrohttpd library appears to require full processing of any data
uploaded by a client request before a request can be sent. With this
change, the clients receive proper authentication errors in all cases.
Now it is also possible to ensure that a DCB stays alive while
a task referring to it is posted from one worker to another.
That will be implemented in a subsequent commit.
The checks whether a request body is present are now done at a higher
level. This removes the need to do the checks at the resource handler
callback, removing duplicated code.
The checks are done by adding constraints to resources that must be
fulfilled by each request.
Added debug assertions to make sure that the core logic of the REST API
resource system works.
The monitors should only be reused if they have the same name and they use
the same module. This way the only difference is in configuration.
Fixed MaxCtrl detection of bad options and altered monitor creation test
to expect correct results. Also improved some of the error messages.
If a destroyed monitor is created again, it will be reused. This should
prevent excessive memory growth when the same monitor is created and
destroyed again.
The feedback system wasn't used and was starting to cause problems on
Debian 9 where the libcurl required different version of OpenSSL than what
MaxScale was linked against.
The two cases where the case-sensitive parser functions were used don't
appear to hold any special meaning. The case-insensitive function should
be used as it implements a superset of functionality compared to the
case-sensitive version.
Allowing requests to be converted to raw HTTP requests allows them to be
propagated to other instances of MaxScale. This should allow multiple
MaxScales to perform the same action in a coherent manner.
A simple clustering mechanism needs to be added to make MaxScale aware of
other instances.
The module command self links now point to an endpoint that executes the
module command. Depending on the type of the module command, either a GET
or a POST request must be made.
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 template class wraps a HashMap such that only a few operations
are allowed. Usage requires specializing a RegistryTraits class
template for each entry type.
