By always starting the session shutdown process by stopping the client
DCB, the manipulation of the session state can be removed from the backend
protocol modules and replaced with a fake hangup event.
Delivering this event via the core allows the actual dcb_close call on the
client DCB to be done only when the client DCB is being handled by a
worker.
Directly closing the client DCB in the backend protocol modules is not
correct anymore as the state of the session doesn't change when the client
DCB is closed. By propagating the shutdown of the session with a fake
hangup to the client DCB, the closing of the DCB is done only once.
Added debug assertions that make sure all DCBs are closed only
once. Removed redundant code in the backend protocol error handling code.
When a double close is detected in a debug build, a debug assertion is
triggered. This will generate a core dump which should help investigate
the double close.
Now detects some erroneous situations before starting switchover.
Switchover can be activated without specifying current master.
In this case, the cluster master server is selected.
DATETIME values in old formats should always be 8 bytes long. This is how
MariaDB 10.2 stores them and only DATETIME2 values are stored with a
fractional part.
According to customer reports collecting the statistics has a significant
impact on the performance. As we don't need that information we can just
as well turn off that.
Further, since maxscale-common now links to the sqlite3-library, no
module needs to do that explicitly.
As the function documentation states, the expected value must be read
again after a call to atomic_cas_ptr. This is due to the fact that if the
values are not the same, the __atomic builtin version will store the
current value into the expected value.
The new value given to the atomic_cas_ptr function was the address of the
new value, not the new value itself. The behavior of the atomic_cas_ptr is
what caused the test to pass on systeems that implement the __atomic
builtins. On older systems that do not implement it, the expected value
was never modified which caused the test to hang.
DECIMAL types that were larger than 8 bytes were not handled
correctly. The current implementation only prints the lowest 8 bytes of
the integer part of the decimal.
The output generated by a failed call to a module command was previously
overwritten with the error messages stored in the module command
subsystem.
In the case of a failure, the proper procedure is to check if the output
generated by the module command conforms to the JSON API error
specification and if it does, combine it with any system generated error
messages. If the output does not conform, it is stored in the "meta" field
of the returned object. This allows all of the generated output to be
saved.
Only asynchronous authenticators require the thread-specific loading of
users as the synchronous ones all share the same data. If the service does
not declare asynchronous capabilities at startup, the users are not
seeded. This prevents unnecessary loading of users at startup.
Setting the query classifier with an absolute path makes it easier to
manage test setup without having to manually resolve the relative path to
the query classifier from the test source directory.
The query classifier was not initialized for the housekeeper thread. This
means that tasks could not use the query classifier and as the avro
conversion is done inside a task, it can't use it.
As the stale status is not a real status bit and it's used to retain the
history of a master, there is no need to print it in any output. This
output will only confuse users now that the stale status will not be
cleared from masters that go down.
The log manager could send two messages if a log message was posted soon
before the log manager was stopped. This caused a debug assertion which
then manifested as a deadlock inside the log manager.
