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.
All monitors (but for MariaDBMon) now handle connection errors in
the same manner.
An exception is MMMon that modifies both the server status and the
monitor status. However, in fact, all other monitors do it the wrong
way and update the server status directly instead of only the monitor
status that then at the end of the loop should be copied to the server
status.
All monitors (but possible for MariaDBMon) now handle the
connecting to the server in the same way, that is, if the
connecting fails, then the status is updated and we return.
This makes the code clearer and reduces race conditions, as the monitor
could be writing SERVER->status while a router is reading it. Also,
the time during which the SERVER struct is locked drops to a fraction.
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.
