Because of how the user-data was read, the same service name could be
found multiple times if the user-search query matched multiple rows. Now
the service names are read to a set, which ignores duplicates. The same
service may be attempted again if the authentication fails and user-data
is fetched again.
Authenticators and monitors now use SSL when configured. The fix has two parts:
1) Removed the extra SSLConfig inside SSLProvider, as SSLContext already contains
the config.
2) When inputting parameter values to mysql_ssl_set(), empty strings are converted
to NULL-pointers as the function expects those for unused values.
The new configuration system relieas upon static varibles being
used for declaring what arguments a particular module uses. To
ensure that the destruction order does not matter, we redundantly
store the needed data (the name).
name_lookup() now returns all results given by getnameinfo(). When searching
for a server, finding one matching address in the lookup-results is enough for
a match.
Also, added a test for name_lookup(). The test is minimal on its own, as hardcoded
test cases are not generally valid.
The new server pam plugin does not always send the first password prompt with the
AuthSwitchRequest-packet. In this case the server expects the client (MaxScale) to
just send the password immediately. MaxScale now checks the length of the packet,
sending the password if the packet is short. This works with both old and new server
versions.
If a master failed during an ongoing session command history replay, it
would be treated as if a normal session command failed which would result
in the already executed session command being re-executed on all servers
at the wrong logical position.
To fix this, the history replay must be distinguished from normal session
command execution. When a connection replaying the history fails, the
query routing simply needs to be attempted again.
When a connection is created, the size of the history that is about to be
replayed is known. Storing this and decrementing it each time a session
command is completed tells us when the Backend has finished replaying the
session command history. This can then be used to distinguish whether a
session command executed on a master should be retried or whether to
simply discard the connection.
If session command execution during server reconnection caused a query to
be queued, the query would be put on the tail end of the queue. This would
cause queries to be reordered if the queue wasn't empty. The correct thing
to do would be to put the next pending query back at the front of the
queue.
If a master reconnection occurred after the session command history was
disabled due to the limit being exceeded, a debug assertion would be hit
in prepare_target. This assert makes sure that a connection can be safely
created to the server which means that in release mode builds the session
state would be inconsistent on the new master.
As this is an unrecoverable situation, the session should stop immediately
even if delayed_retry is enabled. Currently the session will continue
until the delayed retry timeout is hit. This happens due to the fact that
the delayed retry mechanism handles all errors in a similar way.
Now properly checks if configuration and diagnostics functions are ran in either
main() or in the admin worker. This is useful for debugging and enforcing
thread safety.
Also, monitors are now started and stopped in the admin worker.
When a query returns a WSREP error, most of the time it is not something
the client application is expecting. To prevent this from affecting the
client, it can be treated the same way a transaction rollback is treated:
ignore the error and try again.
If a query returned multiple resultsets and the connection was broken
between the resultsets, the backend would not know that parts of the
response were already sent. This is caused by the cyclic nature of the
state machine when multi-result responses are being processed.
To fix the problem, the result size is tracked to know how many bytes have
been sent to the client. This is a backport of the
MySQLProtocol::Result::size from 2.5(develop).
When a RoutingWorker is destructed, all existing local data will
unconditionally be destroyed.
The case in point is the vector<SFilterDef>s that are held as routing
worker local data by the Service. Unless the local data is deleted, the
filter defs will not be deleted at shutdown.
This is somewhat brute-force (but good to have in place nonetheless) as
the deletion of the local data should be done by the Service and before
the routing worker thread has exited.
The expected response counter was not decremented if a transaction replay
was started. This caused the connections to hang which in turn caused the
failure of the mxs1507_trx_stress test case.
When matching hostnames between MaxScale server configuration and the
SHOW SLAVE STATUS-output, use DNS-resolution if a simple string comparison
doesn't find an answer. Results of the resolution are saved to avoid
repeating the operation for the same address.
The settings are different from the other fields in that they should not change
on their own. Most manipulation functions only require the settings.
Also takes into use a class for host and port data.
If the slave's response differs from the master and the slave sent an
error packet, log the contents of the error. This should make it obvious
as to what caused the failure.
The assertion in routeQuery that expects there to be at least one ongoing
query would be triggered if a query was received after a master had failed
but before the session would close. To make sure the internal logic stays
consistent, the error handler should only decrement the expected response
count if the session can continue.
