The code registered both client and backend callbacks for backend
DCBs. This caused the whole connection to hang if backend side throtting
was ever triggered.
The fix to the bug where peer certificates were validated but not required
caused the default behavior to change. The default should've changed at
the same time the fix was made.
GCloud machines has more strict access rights settings. Derect calls of
'chmod' are needed to make all configuration files (e.g. 'fwf/rules') be
accessable by Maxscale.
The Connector-C was changed to always return only the client's charset,
not the actual charset that the connection ends up using. To cope with
this, the code has to use SQL to join the default character set name to
the default collation for it which can be used to extract the numeric ID
of the charset.
The slave backend would be closed twice if it would both respond with a
different result and be closed due to a hangup before the master
responded.
Added a test case that reproduced the problem.
As long as the same thread never handles more than one fatal signal,
multiple fatal signals can be processed. This should guarantee that the
stacktrace is printed into the log while guaranteeing that recursion never
takes place if the handling of a fatal signal causes a fatal signal to be
emitted.
It was possible that the query thread got stuck and never saw the updated
insert_val. Making the variable atomic as well as sleeping in between
queries should prevent it.
By removing replication from the equation, the client IP check is more
stable. The get_client_ip function is only used by bug448 and could be
moved there.
The test repeatedly creates connections which exhausts all the available
TCP connections. The test doesn't appear to test any specific
functionality with the repeated reconnections which means removing it
shouldn't be a problem.
