When the client reauthenticates via COM_CHANGE_USER the new SHA1 needs to
be stored as the backend connections rely on it being up-to-date.
This commit fixes the regression of the mxs548_short_session_change_user
test.
If the reauthentication of a client that is performing a COM_CHANGE_USER
fails, the users need to be reloaded. Without the reloading, the
reauthentication will fail if new users were added after the last loading
of users.
The parameter extraction caused a recursive lock of the server
spinlock. To work around this, an unlocked version of server_get_parameter
is needed.
Ideally, a lock-free setup would be used but due to this being a bug fix,
it will have to be done later on.
Some of the scripts assumed that other scripts would be located in the
same directory where the current script was executed.
Also fixed the SSL connection creation which depended on an obsolete
environment variable causing all out-of-source SSL tests to fail.
The test can now be run outside of the test source directory. Since the
`test_dir` global variable contains the absolute path to the test source,
all copying of configurations and execution of scripts can be done with
minimal changes.
The re-authentication done in MaxScale caused multiple error packets to be
sent for the same COM_CHANGE_USER. In addition to this, the failure of
authentication did not terminate the client connection.
The change in behavior requires the test case to be changed as well.
Since monitors are now freed at MaxScale exit, the server data should be freed. Also,
gtid domain variables are now initialized with a common constant.
Multi-statement SELECTs were properly detected and handled,
but e.g. multi-statement UPDATESs were not, with the result
that erronous warnings were logged.
Now the responses are detected and handled properly.
If a connection is killed but the backend DCBs have not yet received their
thread IDs, the connections can be forcibly closed. This removes the
possibility of stale connections caused by an unfortunately timed KILL
query to a session that has partially connected to some servers.
The purpose of this template class is to provide the
implementation of the monitor C-api. It's to be instantiated
with the class that actually provides the monitor behaviour.
A separate class maxscale::MonitorInstance will be provided
that then in turn implements the behaviour common to most
monitors. So, the structure will be like:
class SomeMonitor : public maxscale::MonitorInstance {...}
extern "C" MXS_MODULE* MXS_CREATE_MODULE()
{
static MXS_MODULE info =
{
...
&maxscale::MonitorApi<SomeMonitor>::s_api,
...
};
return &info;
}
StartMonitor() now takes a MXS_MONITOR_INSTANCE and returns
true, if the monitor could be started and false otherwise.
So, the setup is such that in createInstance(), the instance
data is created and then using startMonitor() and stopMonitor()
the monitor is started/stopped. Finally in destroyInstance(),
the actual instance data is deleted.
The following type name changes
MXS_MONITOR_OBJECT -> MXS_MONITOR_API
MXS_SPECIFIC_MONITOR -> MXS_MONITOR_INSTANCE
Further, the 'handle' instance variable of what used to be
called MXS_MONITOR_OBJECT has been renamed to 'api'.
An example, what used to look like
mon->module->stopMonitor(mon->handle);
now looks like
mon->api->stopMonitor(mon->instance);
which makes it more obvious what is going on.
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.
