The authentication code assumed that the initial request only had
authentication related data. This is not true if the client library
predicts that the authentication will succeed and it sends a query right
after it sends the authentication data.
The authentication phase expects full packets. If the packets aren't
complete a debug assertion would get hit. To detect this, the result of
the extracted buffer needs to be checked.
Returning the results of a query as a set of packets is currently more
efficient. This is mainly due to the fact that each individual packet for
single packet routing is allocated from the heap which causes a
significant loss in performance.
Took the new capability into use in readwritesplit and modified the
reply_is_complete function to work with non-contiguous results.
When the router requires statement based output, the gathering of complete
packets can be skipped as the process of splitting the complete packets
into individual packets implies that only complete packets are handled.
Also added a quicker check for stored protocol commands than a call to
protocol_get_srv_command.
The backend protocol command tracking didn't check whether the session was
the dummy session. The DCB's session is always set to this value when it
is put into the persistent pool.
If a query was processed in the client protocol module when a prepared
statement was being executed by the backend module, the current command
would get overwritten. This caused a debug assertion in readwritesplit to
trigger as the result was neither a single packet nor a collected result.
The RCAP_TYPE_STMT_INPUT capability guarantees that a buffer contains a
complete packet. This information can be used to track the currently
executed command based on the buffer contents which allows asynchronicity
betweent the client and backend protocol. In practice this only comes in
play when routers queue queries for later execution.
The result collection did not reset properly when a non-resultset was
returned for a request. As collected result need to be distinguishable
from single packet responses, a new buffer type was added.
The new buffer type is used by readwritesplit which uses result collection
for preparation of prepared statements.
Moved the current command tracking to the RWBackend class as the command
tracked by the protocol is can change before a response to the executed
command is received.
Removed a false debug assertion in the mxs_mysql_extract_ps_response
function that was triggered when a very large prepared statement response
was processed in multiple parts.
KILL commands are now sent to the backends in an asynchronous manner. As
the LocalClient class is used to connect to the servers, this will cause
an extra connection to be created on top of the original connections
created by the session.
If the user does not have the permissions to execute the KILL, the error
message is currently lost. This could be solved by adding a "result
handler" into the LocalClient class which is called with the result.
When the LocalClient is constructed, it is possible to extract all the
needed information at that time. The only obstacle is the fact that the
LocalClient is constructed at the same time the session is. Since the
client DCB is created before the session, it is safe to extract the shared
data directly from it.
If the client sends data before authentication is complete, it must not be
discarded and it needs to be processed like as if it was sent in a
separate network packet.
When readwritesplit is routing any queued queries, the currently executed
command of the protocol modules needs to be adjusted by
readwritesplit. This is not a true fix but more of a workaround to fix the
problems of queued query execution.
The correct solution would be to move the queued query handling into the
client protocol module so that all components see the same state.
Asserting that only a complete COM_STMT_PREPARE is returned when the
prepared statement preparation is extracted will guarantee that the
protocol works as expected.
The enums exposed by the connector are not intended to be used by the
users of the library. The fact that the protocol, and other, modules used
it was in violation of how the library is intended to be used.
Adding an internal mapping into MaxScale also removes some of the
dependencies that the core has on the connector.
Cleaned up the MaxScale version of the mysql.h header by removing all
unused includes. This revealed a large amount of dependencies on these
removed includes in other files which needed to be fixed.
Also sorted all includes in changed files by type and alphabetical
order. Removed explicit revision history from modified files.
When a COM_CHANGE_USER was executed, it is possible that the server
responds with a AuthSwitchRequest packet instead of an OK packet. In this
case, the server sends a new scramble which must be used to create the 20
byte hash that is expected as the response.
The COM_CHANGE_USER that is sent as a part of the reset process for a
persistent connection did not expect a AuthSwitchRequest packet to be sent
as that implies that the server did not take the authentication fast
path. In this case, an error message needs to be logged stating that the
server requested a different authentication plugin than was expected.
The response handling logic did not always take the last packet for
inspection when a COM_CHANGE_USER was executed. The OK packet will always
be the last one since the COM_CHANGE_USER is the last command that was
sent.
When an unexpected response to a COM_CHANGE_USER is received, it is now
processes and discarded instead of treated as an error. This will allow
further analysis of the situation in addition to possibly solving some of
the problems that the persistent connections have.
Added extra info level logging to relevant parts of the code that deal
with the COM_CHANGE_USER reply processing. This information should allow
tracking of the response state for debugging purposes.
The response to the COM_CHANGE_USER should always be turned into a
contiguous buffer of complete packets. This guarantees that the code that
processes it functions properly.
As COM_QUIT would terminate the connection, there's no need to initiate
the session reset process. Also make sure all buffers are empty before
putting the DCB into the pool.
Added extra debug assertions for parts of the code that are related to the
COM_CHANGE_USER processing.
The EOF packet calculation function in modutil.cc didn't handle the case
where the payload exceeded maximum packet size and could mistake binary
data for a ERR packet.
The state of a multi-packet payload is now exposed by the
modutil_count_signal_packets function. This allows proper handling of
large multi-packet payloads.
Added minor improvements to mxs1110_16mb to handle testing of this change.
When a persistent connection is reused, a COM_CHANGE_USER command is
executed to reset the session state. If the reused connection was closed
before the response to the COM_CHANGE_USER was received and taken into use
by another connection, another COM_CHANGE_USER would be sent to, again,
reset the session state. Due to the fact that the first response is still
on its way, it will appear as if two responses are generated for a single
COM_CHANGE_USER.
The way to fix this is to avoid putting connections that haven't been
successfully reset into the connection pool.
When a session is being closed in a controlled manner, i.e. a COM_QUIT is
received from the client, it is possible to deduce from this fact that the
backend connections are very likely to be idle. This can be used as an
additional qualification that must be met by all connections before they
can be candidates for connection pooling.
This assumption will not hold with batched and asynchronous queries. In
this case it is possible that the COM_QUIT is received from the client
before even the first result from the backend is read. For this to work,
the protocol module would need to track the number and state of expected
responses.
Only the first error for each DCB should invoke the error handler
routine. All other errors for the same DCB should be ignored.
In practice this appears to happen when epoll return two different types
of error events for the same DCB.
When a LOAD DATA LOCAL INFILE is done, the last packet is an empty packet
which does not contain the command byte. Some parts of the MySQL protocol
modules expected that a command is always present. The proper way to
handle this is to use the mxs_mysql_get_command function which does bounds
checking.
If a connection has not been fully established (i.e. authentication has
been completed) then it should not be considered as a connection pool
candidate.
The setting parsing is now similar to the other server settings.
The header is printed if log_info is on.
Changed the setting name to simply "proxy_protocol".
Updated documentation.
The backend server can send a response even if the client hasn't sent a
request. One case where this occurs is when the server is shutting
down. The internal logic of readwritesplit can't handle unexpected states
gracefully so the safest thing to do is to just ignore them and send the
responses to the client.
The COM_STMT_FETCH queries are always executed when the result has not
been fully read. This means that the statement queuing code needs to allow
COM_STMT_FETCH commands to pass if a statement is being executed but the
command queue is empty.
Session commands that will not return a response can be completed
immediately. This requires some special code in the readwritesplit Backend
class implementation as well as a small addition to the Backend class
itself.
Since not all commands expect a response from the server, the queued query
routing function needs some adjustment. The routing of queued queries
should be attempted until a command which expects a response is found or
the queue is empty.
By properly handling these types of session commands, the router can
enable the execution of COM_STMT_CLOSE and COM_STMT_RESET on all
servers. This will prevent resource leakages in the server and allow
proper handling of COM_STMT type command.
When a COM_STMT_EXECUTE or a COM_STMT_SEND_LONG_DATA command is executed,
the query type of the prepared statement is used. This allows read-only
prepared statements to be load balanced across slaves.
Mapping the handles returned to the client to a session command ID allows
the mapping of client handle to the backend specific handle. Currently,
the mapping is used for diagnostic output only.
The mxs_mysql_extract_ps_response function extracts the binary protocol
prepared statement components and stores them in a common structure.
The mxs_mysql_get_command extracts the command byte from a GWBUF object
containing a complete MySQL packet.
