In order to make it visible that the types contain C++
members, the following types were renamed:
CHANGE_MASTER_OPTIONS -> ChangeMasterOptions
MASTER_SERVER_CNF -> MasterServerConfig
Functions where also changed to take const refs were appropriate.
In order support the possiblity for having multiple alternative
masters for the binlog server, we need to have multiple configs
around.
Originally the config values were stored as 'char *':s, which
would have made the lifetime management of the strings laborious
and error prone.
Now, the options are stored as std::string:s, which makes the
lifetime management a non-issue.
When receiving a command, such as
CHANGE MASTER TO MASTER_HOST = '127.0.0.1' ...
when the value is extracted, the quotes are removed before the value
is returned.
Firstly, BLR does not anyway anywhere enforce that quotes are present
where they should be and, secondly, BLR currently does de-quoting all
over the place and with this change, all those places can be simplified.
The configuration updating in readwritesplit was the inspiration for the
mxs::rworker_local type. Due to this, taking it into use simply means that
the type changes from Config to mxs::rworker_local<Config>.
Given that worker.hh was public, it made sense to make routingworker.hh
public as well. This removes the need to include private headers in
modules and allows C++ constructs to be used in C++ code when previously
only the C API was available.
By storing the data gathere by readwritesplit inside the session, the
protocol will be aware of the state of the LOAD DATA LOCAL INFILE
execution. This prevents misinterpretation of the data which previously
led to closed connections, effectively rendering LOAD DATA LOCAL INFILE
unusable.
This change is a temporary solution to a problem that needs to be solved
at the protocol level. The changes required to implement this are too big
to add into a bug fix release.
The master reconnection in the binlogrouter used the housekeeper
recursively. This is no longer supported and the delayed worker call
mechanism should be used in its stead.
The maxscale_is_shutting_down function is used to detect when MaxScale
should stop. This fixes a race condition in the code where the workers has
not yet been initialized but a termination signal has been received. It
also replaces the misuse of the service_should_stop variable with a proper
function.
The paths were wrong in the scripts used to run tests. The same problem
was in the CMake files that used CMAKE_SOURCE_DIR instead of
CMAKE_CURRENT_SOURCE_DIR.
Added missing check for BUILD_SYSTEM_TESTS in avrorouter for the
workaround to building without all dependencies present.
The offsets in the events were wrong if MaxScale was restarted in the
middle of a binlog. This was caused by the fact that the FDE event
contains information on binlog checksums which is required for a correct
interpretation of the binlog. The FDE event was only read when the binlog
was first opened when it needs to be read every time the binlog is opened.
As a JSON object can never start with the ERR prefix, it is safe to check
it for all requests. Also fixed the missing newline in the avrorouter
error message.
- The ones that were not used were removed.
- The ones that were used were moved close to the actual type.
In most cases some values were missing and if the definition is
close to the type there is a remote chance that they will stay
in sync. If detached, they surely will not.
Removed skygw_utils and relate files along with the old log manager
code. Also removed file flushing due to it being redundant; messages are
written to the file immediately. Adjusted tests to accommodate this
change.
Replaced with explicit dependency on pthread.h. Acceptable since
this is effectively for debugging purposes and could at some point
be removed entirelly.
The custom random number generator can now be replaced with a C++11
RNG. This greatly improves the reliability and trustworthiness of it.
In addition to this, the conversion of the RNG to a thread-local object
removes the race condition that was present in the previous
implementation. It also theoretically improves performance by a tiny bit.
This is the first step in some cleanup of the Worker interface.
The execution mode must now be explicitly specified, but that is
just a temporary step. Further down the road, _posting_ will
*always* mean via the message loop while _executing_ will optionally
and by default mean direct execution if the calling thread is that
of the worker.
