As all connections should be accepted via dcb_accept, it is the optimal
place to calculate how many open client connections per service there
are. The decrementation should be done when the session is closed instead
of when the call to dcb_close for the client DCB is done. This allows the
client count to be the absolute reference count that sessions have to a
service.
The current client count is a duplicate counter that should match the
n_current value in SERVICE_STATS. The former does differ from the latter
in that it does the incrementation when the client DCB is accepted instead
of when the session is created.
If a client is executing a COM_CHANGE_USER command and the
reauthentication of the client fails, no error message would be logged
about the failure of the reauthentication process and only a routing
failure message would be logged.
The function implemented redundant functionality and replacement with
modutil_get_next_MySQL_packet was planned.
When faced with a packet header spread over multiple buffers, the packet
length calculation would read past the buffer end. This is fixed by taking
modutil_get_next_MySQL_packet into use.
Identical behavior to the old function is achieved by calling
gwbuf_make_contiguous for each packet to store them in a contiguous area
of memory. This should be either removed and only done when
RCAP_TYPE_CONTIGUOUS_INPUT is requested or be made an innate feature of
statement based routing.
The debug assertion introduced by commit 3d1c2b421a fails when a
COM_CHANGE_USER was executed. This was caused by the fact that the
authentication data was being interpreted as a command when it should've
been ignored.
Added a debug assertion into the reauthentication code to make sure the
current command remains the same.
When a client connection is closed by MaxScale before the client initiates
a controlled closing of the connection, an error message is sent. This
error message now also explains why the connection was closed to make
problem resolution easier.
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.
When the client reauthenticates via COM_CHANGE_USER the new SHA1 needs to
be stored as the backend connections rely on it being up-to-date.
This commit fixes the regression of the mxs548_short_session_change_user
test.
The re-authentication done in MaxScale caused multiple error packets to be
sent for the same COM_CHANGE_USER. In addition to this, the failure of
authentication did not terminate the client connection.
The change in behavior requires the test case to be changed as well.
To support a wider range of client connectors, MaxScale should respond
with an AuthSwitchRequest packet to all COM_CHANGE_USER commands. Only
MariaDB connectors understand the OK packet as the only response to a
COM_CHANGE_USER but all connectors understand the AuthSwitchRequest
packet.
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.
The current command needs to be updated before the queries are actually
routed. This allows the KILL command detection and processing to correctly
work.
With the configuration entry
dump_last_statements=[never|on_close|on_error]
you can now specify when and if to dump the last statements
of of a session.
With the configuration entry
retain_last_statements=<unsigned>
or the debug flag '--debug=retain-last-statements=<unsigned>',
MaxScale will store the specified number of last statements
for each session. By calling
session_dump_statements(session);
MaxScale will dump the last statements as NOTICE messages.
For debugging purposes.
With the changes in this commit it is possible to add and remove
MaxScale specific user variables. A MaxScale specific user variable
is a user variable that is interpreted by MaxScale and that
potentially changes the behaviour of MaxScale.
MaxScale specific user variables are of the format "@maxscale.x.y"
where "@maxscale" is a mandatory prefix, x a scope identifying the
component that handles the variable and y the component specific
variable. So, a variable might be called e.g. "@maxscale.cache.enabled".
The scope "core" is reserved (although not enforced yet) to MaxScale
itself.
The idea is that although MaxScale catches these, they are passed
through to the server. The benefit of this is that we do not need to
detect e.g. "SELECT @maxscale.cache.enabled", but can let the result
be returned from the server.
The interpretation of a provided value is handled by the component that
adds the variable. In a subsequent commit, it will be possible for a
component to reject a value, which will then cause an error to be
returned to the client.
There are 3 new functions:
- session_add_variable() using which a variable is added,
- session_remove_variable() using which a variable is removed, and
- session_set_variable_value().
The two former ones are to be called by components, the last one by
the protocol that catches the "set @maxscale..." statements.
By always starting the session shutdown process by stopping the client
DCB, the manipulation of the session state can be removed from the backend
protocol modules and replaced with a fake hangup event.
Delivering this event via the core allows the actual dcb_close call on the
client DCB to be done only when the client DCB is being handled by a
worker.
If a DCB is closed before a response to the handshake packet is received,
the DCB's session will point to the dummy session. In this case no error
should be written to the DCB.
