Copying a std::deque<mxs::Buffer> would cause a compilation failure due to
ambiguity between the copy-assignment and move-assignment
operators. Explicitly constructing a temporary object retains the strong
exception guarantee but prevents the ambiguity.
The SESSION_TRACK_SCHEMA tracking capability handling assumed an encoding
integer in the data. This value does not exist for the data returned by
schema change or session state tracking.
With the changes to the DCB handling, the service pointer of a client DCB
must always be assigned.
Also removed the unnecessary parentheses around the comparison.
Large session commands weren't properly handled which caused the router to
think that the trailing end of a multi-packet query was actually a new
query.
This cannot be confidently solved in 2.2 which is why the router session
is now closed the moment a large session command is noticed.
Only commands that can contain an SQL statements should be stored for
retrying (COM_QUERY and COM_EXECUTE). Other commands are either session
commands or do not work with query retrying.
Each `show` type command that takes a resource name now also has a version
that prints all resources of that type.
Added test cases for newly added commands.
The requesting of a resource and the processing was integrated into one
function. Moving the processing part into a separate function allows easy
processing of resource collections.
This refactoring made the creation of the getCollectionAsResource function
possible. It enables `show` type commands for resouce collections
(servers, services etc.).
The state of each individual listener is now displayed in the REST
API. Created common functions for printing the listener state and took
them into use. Added the new state into MaxCtrl output.
The setup contains a three node master-slave cluster with both
readwritesplit and readconnroute.
Removed the duplication of the configuration files in the README and
provided links instead.
Being able to perform raw REST API calls that leverage the value
extraction capabilities of Node.js gives more control to the end user. It
also doubles as a handy tool for creating scripts that only require one
particular value from the REST API.
The docker image now simply installs the latest MaxScale version instead
of building it. This significantly reduces the amount of maintenance that
the image requires.
Updated the configurations to allow runtime definition of servers and
updated README.md to reflect the changes in the files. Pointed links to
2.2 instead of develop. Removed text from the readme that was not strictly
related to running the MaxScale image.
Worker is now the base class of all workers. It has a message
queue and can be run in a thread of its own, or in the calling
thread. Worker can not be used as such, but a concrete worker
class must be derived from it. Currently there is only one
concrete class RoutingWorker.
There is some overlapping in functionality between Worker and
RoutingWorker, as there is e.g. a need for broadcasting a
message to all routing workers, but not to other workers.
Currently other workers can not be created as the array for
holding the pointers to the workers is exactly as large as
there will be RoutingWorkers. That will be changed so that
the maximum number of threads is hardwired to some ridiculous
value such as 128. That's the first step in the path towards
a situation where the number of worker threads can be changed
at runtime.
A new class mxs::Worker will be introduced and mxs::RoutingWorker
will be inherited from that. mxs::Worker will basically only be a
thread with a message-loop.
Once available, all current non-worker threads (but the one
implicitly created by microhttpd) can be creating by inheriting
from that; in practice that means the housekeeping thread, all
monitor threads and possibly the logging thread.
The benefit of this arrangement is that there then will be a general
mechanism for cross thread communication without having to use any
shared data structures.
If maxadmin connections are handled by different workers, then
there may be a deadlock if some maxadmin command requires
communication with all workers.
Namely, in that case a message will be sent to all other workers
but the current one, but that message will not be handled if that
other worker at that point sits in the debugcmd_lock spinlock
in debugcmd.c:execute_cmd().
We can prevent that deadlock from happening simply by ensuring
that all maxadmin connections are handled by one thread.
Auto types aren't very neat as return values because they move the burden
of knowledge to the reader. Using an explicit, and somewhat
self-explanatory, type makes it easier to assess the code without knowing
the implementation of the type.
The commands needs to be handled separately from the rest of the result
types.
Added a test case that reproduces the problem and verifies that the change
in code fixes it.
When a LOAD DATA LOCAL INFILE finishes, the client sends an empty
packet. The second case when the client sends an empty packet when the
previous packet was exactly 0xffffff bytes long. These two packets were
confused which caused the internal state to temporarily flip from inactive
to ending and back to inactive.
The aforementioned flip-flopping didn't have any practical differences but
it was caught by a debug assertion.
