The configuring of the monitor instance is now performed in a
separate function. That is in preparation for the moving of the
start function to maxscale::MonitorInstance.
- All monitors (but MariaDBMon for the time being) inherit
from that.
- All common member variables moved to that class. Still
manipulated in derived classes.
In subsequent commits common functionality will be moved to
that class.
By relying on the server to tell us that it is requesting the loading of a
local infile, we can remove one state from the state machine that governs
the loading of local files. It also removes the need to handle error and
success cases separately.
A side-effect of this change is that execution of multi-statement LOAD
DATA LOCAL INFILE no longer hangs. This is done by checking whether the
completion of one command initiates a new load.
The current code recursively checks the reply state and clones the
buffers. Neither of these are required nor should they be done but
refactoring the code is to be done in a separate commit.
Added two helper functions that are used to detect requests for local
infiles and to extract the total packet length from a non-contiguous
GWBUF.
From 10.1.32, 10.2.14 and 10.3.6 onwards, there is an
information_schema plugin called DISKS using which information
about the disk space situation on the server can be obtained.
Subsequent commits will add configuration options for specifying
limits and take the functionality in use in monitors where it makes
sense.
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.
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.
CreateInstance() (renamed from initMonitor()) and destroyInstance()
(renamed from finishMonitor()) have now tentatively been
implemented for all monitors.
Next step is to
1) change the prototype of startMonitor() to
bool (*startMonitor)(MXS_SPECIFIC_MONITOR*,
const MXS_MONITOR_PARAMETER*);
and assume that mon->handle will always contain the
instance,
2) not delete any data in stopMonitor(),
3) add monitorCreateAll() that calls createInstance() for all
monitors (and call that in main()), and
4) add monitorDestroyAll() that calls destroyInstance() for
all monitors (and call that in main()).
Now, all monitor functions but startMonitor takes a
MXS_SPECIFIC_MONITOR instead of MXS_MONITOR. That is, startMonitor
is now like a static factory member returning a new specific
monitor instance and the other functions are like member functions
of that instance.
Instead of using void there's now a MXS_SPECIFIC_MONITOR struct
from which monitor specific types can be derived. This change
does not bring about other benefits than a bit of clarity but
this is the first step in clearing up the monitor API.
Returning the length of the value instead of a boolean allows the user to
know when the parameter value exceeded the buffer size passed as the
parameter.
To support a wider range of client connectors, MaxScale should respond
with an AuthSwitchRequest packet to all COM_CHANGE_USER commands. Only
MariaDB connectors understand the OK packet as the only response to a
COM_CHANGE_USER but all connectors understand the AuthSwitchRequest
packet.
The individual servers were missing a statistic that would give an
estimated query count. As there is no simple way to count queries for all
modules, counting the number of routed protocol packets is a suitable
substitute.
Session commands that span multiple packets are now allowed and will
work. However, if one is executed the session command history is disabled
as no interface for appending to session commands exists.
The backend protocol modules now also correctly track the current
command. This was a pre-requisite for large session commands as they
needed to be gathered into a single buffer and to do this the current
command had to be accurate.
Updated tests to expect success instead of failure for large prepared
statements.
Parameter deprecation on the module level means that the parameter should
no longer be used but using it will not cause an error. If a deprecated
parameter is used, it will be removed from the configuration.
The two-part shutdown procedure for the housekeeper was not needed and
caused problems if SIGINT wasn't raised. Since the main thread returns to
the main function, a single shutdown function is all that the housekeeper
needs to function.
Moved all the shutdown related code into Housekeeper::stop to remove the
waiting for the thread in the destructor.
The Checksum class defines an interface which the SHA1Checksum and
CRC32Checksum implement.
Added test unit test cases to verify that the checksums work and perform
as expected.
