Reading the binlog event header in a separate function makes it easier to
comprehend. Cleaned up some unused variables and code that would is not
used.
This clarifies what parts of the router are specific to the binlogrouter
and what are common between the binlogrouter and avrorouter.
Ideally, the two modules would use the same infrastructure to handle the
processing of replication events. This is the first, albeit small, step
towards making the code in the binlogrouter the common infrastructure.
The Avro instance is now created inside a static class method. This brings
it in line with how other modules create instances.
Converted all strings to std::string and updated their usage.
By storing the table maps in a std::unordered_map, the storage of mapped
tables is made dynamic. This also makes the management of mapped tables a
lot more robust.
Using std::string for names removes the need to handle memory
allocation. Moving the column attributes into a class of its own greatly
simplifies the creation of the TABLE_CREATE as well as modifications that
are done to it.
The HASHTABLE can be replaced with std::unordered_map. This simplifies the
management by making the deletion of old objects automatic.
More cleanup and refactoring is needed to make the contained classes
cleaner.
The avrorouter no longer uses the housekeeper for the conversion
task. This prevents the deadlock which could occur when clients were
notified at the same time that the binlogrouter was adding a master
reconnection task.
The instance and session objects are now C++ structs. The next pointers
for the sessions was removed as it is not the appropriate place to store
this information. This means that the client notification functionality is
broken in this commit.
The test may fail if the client/maxscale/mariadb combo is too slow.
TODO, maybe: today I saw mysql_query() hang (in a poll) when maxscale
disconnected. Is there something that can be done about that?
I added a source directory, base, for stuff that should become part of a common
utility library in the future.
Defining the [maxscale] section in a configuration file that is not the
root configuration file is now treated as an error instead of silently
ignored.
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.
testrules.cc had a signed to unsigned comparison and it used lambda
functions (which are not supported in CentOS 6).
The keywords struct in hintparser.cc needed to be declared static in order
for it to compile.
When large binary protocol packets were handled, a part of the data was
replaced with a non-existing PS ID.
The replacement of the client PS ID to the internal ID and the replacement
of the internal ID to the server specific ID must only be done if a large
packet is not being processed. This can be done on the router level
without adding knowledge of large packets to the RWBackend class.
A specific function, RWBackend::continue_write, was added to make it clear
that the buffer being written is a part of a larger query. The base class
Backend::write could be used but its usage is not self-explanatory.
A slight increase of the timeout to 300 seconds should solve some test
failures. The test is extremely hard on the machines and even when run
locally, the test slows down to a crawl.
The MariaDB implementation allows the last GTID to be tracked with the
`last_gtid` variable. To do this, the configuration option
`session_track_system_variables=last_gtid` must be used or it must be
enabled at runtime.
The `drain server` commands removes a server from all services and waits
until all the connections for it are closed. Once the server is no longer
in use, it will be set into maintenance mode and put back into the
services where it was removed from.
The `show sessions` output now displays the servers each session is
connected to along with their connections IDs. The output format of the
data is not the most compact representation but it should make it
relatively easy to parse.
The protocol now allows protocol modules to return JSON formatted
information about the protocol module internals. Currently this is only
implemented by the mariadbbackend module and it returns the current
connection ID on the backend server.
Removed unused and properly documented all entry points in the protocol
module API. As the removal of the `session` entry point is an backwards
incompatible change, the protocol API version was updated.
The connections that relate to a particular session are now a part of the
sessions resource. Currently, only the generic information is stored for
each connection (id and server name).
Now that the set of DCBs is stored in the session, it can be used to speed
up the handling of the KILL command processing by stopping when the first
related DCB is found.
By storing a link to the backend DCBs in the session object itself, we can
reach all related objects from the session. This removes the need to
iterate over all DCBs to find the set of related DCBs.
DCBs will only be used in conjunction with RoutingWorkers and
hence RoutingWorker and not just Worker must be used when looking
for the current worker and worker id.
The reason is that RoutingWorker cheats; the current worker id is
set to 0 at initialization time, which indicates that a worker would
be running although it isn't.
The reason is that as listeners are created before any worker has
been started, that arrangement ensures that listening DCBs are
book-kept in the worker running in the main thread.
Now, that is a kludge. It ought to be changed so that a, say,
MainRoutingWorker class is introduced that in its run function
initializes MaxScale and then continues running as any regular
RoutingWorker. In due time.
