The relationships of a service are handled by the service alteration
code. Currently, only server relationships are handled by the code in
question and filter relationships are ignored.
If an invalid value or type is given to the REST API, having the expected
type as well as the given type make problem resolution easier.
Also added a value check into MaxCtrl for listener ports.
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.
The runtime configuration JSON validation now allows multiple
relationships to be verified at one time. This makes it easier to validate
all objects using the same framework.
The C++ version with the lock guard is easier to manage when there are
multiple return points from a function. It also makes sure that the lock
is freed after it's used.
The configuration system that modules use allows the SSL parameter
validation to be simplified. It should also provide more consistent error
messages for similar types of errors.
The SSL_LISTENER initialization is now done in one step. There was no good
reason to do it in two separate steps for listeners but in one step for
servers.
The `ssl` parameter now also accepts boolean values. As the parameter
behaves like a boolean and looks like a boolean, it ought to be a
boolean. It still accepts the custom `required` and `disabled` values
simply for backwards compatibility.
Also added the missing freeing functions for the SSL_LISTENER type. This
prevents failed SSL_LISTENER creations from leaking memory.
The common monitor parameters are now stored as module-style
parameters. This makes the error reporting as well as the type checks for
the parameters consistent with parameters declared by the modules.
The same mechanism that is used for modules can be used for the
configuration of the core objects. This removes the need for the redundant
code that validates various values that is already present in the code
that modules use.
If a router parameter has no default value, the previous value would be
returned as an empty string. A debug assertion would be triggered when a
parameter of this type was altered.
When a new router parameter is encountered and the alteration fails, the
modified value in the service need to be removed. Previously, the new
value would have been stored in the service with an empty value which
would have caused problems.
Extended the test to cover modifications to readconnroute as well as do
checks on detection of invalid parameters.
Also allowed modifications to router_options at runtime.
MonitorDestroy() (renamed to monitor_destroy()) will be used for
actually destroying the monitor instance, that is, execute
destroyInstance() on the loaded module instance and freeing the
the monitor instance.
TODO: monitor_deactivate() could do all the stuff which is currently
done to the monitor in config_runtime(), instead of just
turning off the flag.
The old hkheartbeat variable was changed to the mxs_clock() function that
simply wraps an atomic load of the variable. This allows it to be
correctly read by MaxScale as well as opening up the possibility of
converting the value load to a relaxed memory order read.
Renamed the header and associated macros. Removed inclusion of the
heartbeat header from the housekeeper header and added it to the files
that were missing it.
The internal header directory conflicted with in-source builds causing a
build failure. This is fixed by renaming the internal header directory to
something other than maxscale.
The renaming pointed out a few problems in a couple of source files that
appeared to include internal headers when the headers were in fact public
headers.
Fixed maxctrl in-source builds by making the copying of the sources
optional.
The error message was not 100% accurate about the value. In addition to
that, neither the value itself nor the monitor or parameter names were
printed in the error message.
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.
As the passive parameter is only used by the failover and the failover can
only be initiated by the monitor, there is no true need to synchronize the
reads and write of this parameter.
As all runtime changes are protected by the runtime lock, only partial
reads are of concern. For the supported platforms, this is not a practical
problem and it only confuses the reader when other variables are modified
without atomic operations.
Using timestamps to detect whether MaxScale was active or passive can
cause problems if multiple events happen at the same time. This can be
avoided by separating events into actively observed and passively observed
events. This clarifies the logic by removing the ambiguity of timestamps.
As the monitoring threads are separate from the worker threads, it is
prudent to use atomic operations to modify and read the state of the
MaxScale. This will impose an happens-before relation between MaxScale
being set into passive mode and events being classified as being passively
observed.
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 `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.
