The removal of a server from a service is intended to affect only new
sessions.
Added a test that checks that the connections are kept open even if the
server is removed from the service.
MXS-1412: while discarding a result set don't buffer any data: this
avoids to store useless data.
Additionally the colum definitions buffer is used instead of the offset
value.
By processing each buffer individually, the need to iterate over the whole
resultset is removed. Profiling showed that most of the time was spent
navigating the linked list of buffers when an offset into the whole
resultset was used instead of an offset to the individual response buffer.
Basically it would be trivial to report far more operations
explicitly, but for the fact that the values in qc_query_op_t
currently, quite unnecessarily, form a bitmask.
In 2.2 that is no longer the case, so other operations will be
added there.
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 test attempted to copy the generated CSV file from the MaxScale server
when in fact it was on the master server. Removed HEAVY label from the
test as it takes about 10 seconds to run.
Cherry-picked from commit f80cde2af149fda9c47d8f9131f82527b76af487.
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.
The automatic reconnection feature of the Connector-C was not
enabled. Enabling it should reduce the amount of false positives that the
monitors pick up.
If the session id is known, it will be logged together with all
messages. If present, the session id appears, enclosed in paranthesis,
right after the message category. E.g.
2017-08-30 12:20:49 warning: (4711) [masking] The rule ...
Conceptually this is a cherry-pick of commit
67efd1daeabbc398b8a8fbc0cd02c2af26e4cb6c (2.2), but too much has
changed to actually be able to cherry-pick that commit.
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.
Before this change, only db2.t2 was reported as table name for a
select like
select * from db1.t1 union select * from db2.t2
With this change, db1.t1 and db2.t2 are reported.
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 function that printed all sessions assumed that all client DCBs had
valid, non-dummy sessions. It is possible that a client with a dummy
session is the list. These sessions should be ignored.
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.
The buffer used to store the hexadecimal string was one byte too
short. This caused the trailing null terminator to be written into
unallocated memory.
The pointer manipulation in modutil_count_statements assumed that if a
semicolon is found, it is not the last character in the buffer. It also
assumed that the buffer contained at least one readable character.
If the binlog has binlog checksums enabled, the extra checksum bytes are
removed from the end of the event. The avrorouter assumes that whatever
caused the binlogs to appear in the first place already checked that the
checksums are OK.
Also removed one extra byte being added to the length of all query events.
