Session log files are now regularly checked for existence. If the log file
does not exist (likely because it has been rotated), a new log file is created.
Worker::STOPPED -> MONITOR_STATE_STOPPED
Worker::POLLING -> MONITOR_STATE_RUNNING
Worker::PROCESSING -> MONITOR_STATE_RUNNING
By defining the monitor state from the worker state there is
no risk they will ever get out of sync. And there is one thing
less to maintain.
As m_servers is a member of Monitor, it is better if the closing
of the MYSQL connections is done there, so that derived classes
do not need to remember doing that.
When the servers of a service are defined by a monitor, then
at startup all servers of the monitor should be added to relevant
services. Likewise, when a server is added to or removed from a
monitor at runtime, those changes should affect services as well.
However, whether that should happen or not depends upon the monitor.
In the case of the Clustrix monitor this should not happen as it
adds and removes servers depending on the runtime state of the
Clustrix cluster.
If the servers of a service are defined by a monitor (the config
has 'cluster=SomeMonitor'), then the addition of a server to a
a monitor should lead to that server being added to the service.
The services whose servers are defined using a monitor, will
now be populated from the monitor.
Note, no consideration has yet been given to runtime changes.
The Avro libraries appear to sometimes overwrite the CMake
variables. Patching out the code that looks for the libraries should
prevent the library from ever being linked against the snappy libraries.
The documentation stated that at most `max_sescmd_history` commands were
kept but in reality the number of commands kept in the history was one
command smaller than what was documented.
Moved hintfilter documentation to the correct place and cleaned it
up. Added a note at the start of the syntax documentation about the
behavior of the hint parsing to warn users of possible unexpected
behavior. The hint parsing could really use some refactoring to make it
more manageable which is why the preliminary fix version of the bug will
be 2.4.
By repeatedly doing reads instead of one read per second, it is more
likely that MXS-2311 is reproduced. This is still not a deterministic
process but in theory it can reproduce the problem.
If an ignorable packet was followed by more than one queued packets, they
would all get routed in the same batch. This would cause unexpected
replies from the server if multiple ignorable packets were queued up.
The manipulation functions are currently static so that the container can be initialized
if required. This will be fixed later.
The new functions are taken into use in monitor management.
Using a void return value as an integer results in undefined behavior.
apparently in this case it doesn't translate into a crash and instead only
manifests itself when all the planets align.
