Tracking how many times the monitor has performed its monitoring allows
the test framework to consistently wait for an event instead of waiting
for a hard-coded time period. The MaxCtrl `api get` command can be used to
easily extract the numeric value.
-Wunused-result warning in test_logthrottling.cc was causing error when
trying to build MaxScale from source. This warning can be silenced with by
putting the function triggering the warning in if-clause.
If the starting of a transaction was interrupted by a server failure, the
query needs to be retried. This needs to be done as a transaction replay
to keep the routing logic consistent and simple.
When a non-autocommit transaction is interrupted, there will be no query
in progress and no replaying is needed. To handle this case, the replay
initialization logic needed to be altered to treat truly empty
transactions as a success case.
The code that selects the candidate backend always returned the root
master if the server bitmask contained the master bit. This should only be
done if the master bit is the only bit in the bitmask and when there are
other bits, the normal candidate selection code should be used.
Also added a query to the expanded test case to make sure the connection
actually works.
The two operations return different types of results and need to be
treated differently in order for them to be handled correctly in 2.2.
This fixes the unexpected internal state errors that happened in all 2.2
versions due to a wrong assumption made by readwritesplit. This fix is not
necessary for newer versions as the LOAD DATA LOCAL INFILE processing is
done with a simpler, and more robust, method.
Commit 67386980e327ad063b24cb55971cf44f4930e241 caused the actual events
to be ignored. This meant that the larger event size was assumed for all
events. In most cases this works but it is not the correct way to do it.
Start/stop now provided by MonitorInstance. The thread main
function is now virtual and overriden by MariaDBMonitor. Some
additional refactoring is necessary in order to be able to allow
MonitorInstance to handle the main loop.
As all other monitors MMMon now only manipulates the pending_status
of the monitor object during analysis and only in the end touches
the server status.
Instead of continuously updating the status of the server object,
the monitor should update the pending_status of the monitor object
and then only at the end update the status of the server object.
Instead of continuously updating the status of the server object,
the monitor should update the pending_status of the monitor object
and then only at the end update the status of the server object.
Instead of continuously updating the status of the server object,
the monitor should update the pending_status of the monitor object
and then only at the end update the status of the server object.
