KILL commands are now sent to the backends in an asynchronous manner. As
the LocalClient class is used to connect to the servers, this will cause
an extra connection to be created on top of the original connections
created by the session.
If the user does not have the permissions to execute the KILL, the error
message is currently lost. This could be solved by adding a "result
handler" into the LocalClient class which is called with the result.
When the LocalClient is constructed, it is possible to extract all the
needed information at that time. The only obstacle is the fact that the
LocalClient is constructed at the same time the session is. Since the
client DCB is created before the session, it is safe to extract the shared
data directly from it.
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 stack traces weren't logged as the LOG_ALERT priority wasn't enabled
by default. As an alert is intended to be something that must leave a
trace somewhere, and as such, it must not be possible to disable it. For
this reason, it is acceptable to always log the message if the priority is
LOG_ALERT.
Added the -rdynamic linker flag so that all symbols are exported when
linking MaxScale.
As the stack trace is printed in a signal handler, the first attempt
should be to print the stack trace to the standard output. This way the
output is printed before an attempt to use malloc is made when it is
logged to the logfile.
If the client sends data before authentication is complete, it must not be
discarded and it needs to be processed like as if it was sent in a
separate network packet.
If a module command returns a json object, it will always be
returned to the caller, irrespective of whether the command
itself succeeded or not.
Otherwise, if the command failed and if the module command has
set an error message, that error message will be returned as a
json object containing the error message.
Since the module command interface was expanded to include a JSON output
parameter, there is no longer a need for an output DCB. As the JSON can be
printed by both maxadmin and the REST API, this allows the removal of
explicit output formatting in module commands.
If the authenticator option is enabled, no users are loaded and no errors
have occurred in the user loading process, the service credentials are
injected.
The `script_timeout` and `journal_max_age` parameters weren't handled in
the monitor alteration code.
Also added missing documentation to maxadmin help output for
`alter monitor`.
When the database firewall filter is used in white-list mode,
'USE <db>' should be allowed. When connecting, it is always
possible to specify the database anyway so restricting
'USE <db>' serves no purpose.
If a script variable resolves to an empty string, the replacement attempt
will fail with an out-of-memory error. The following realloc call will
fail as it requires a positive value for the new size.
The result of the authentication should be ignored but the scramble that
is calculated as a side-effect still needs to be stored. This can be done
by altering the SQL used to get the matching row to only match on the
username, not the network address.
Also expanded the test case to cover the use of bad credentials.
The avrorouter now uses the parameters from the source service. This
removes the need for redundant parameter definition in the avrorouter
service when they are defined in the binlogrouter service as parameters.
Added some missing configuration sanity checks and updated the tutorial to
reflect the new configuration method introduced in 2.1.
The documentation stated that the binlogrouter would use the cache
directory to store the binary log files. In reality, there was no default
value and the service would fail to start without a binlogdir parameter.
The router now uses the data directory (/var/lib/maxscale/) to store the
binary logs.
Set the default value of mariadb10-compatibility to true. This is in line
with the fact that most installations should use the router with a MariaDB
10.0 server or newer.
If a prepared statement fails to execute on a backend server, no prepared
statement ID is returned. As the connection to the slave backend will be
closed when the result of a session command differs from the master's
response, there's no need to even attempt extracting the response.
This change avoids the triggering of a false positive in
mxs_mysql_extract_ps_response when an attempt to extract a
COM_STMT_PREPARE response is made on a response that isn't a
COM_STMT_PREPARE response.
