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.
If the client DCB of the session was passed into the function, it was
possible that the session pointer for it was already set to null. The
session pointer of an open DCB is never null but a client DCB's session
pointer can be null if accessed via the MXS_SESSION object.
The pkill executable is provided by the same package that provides ps
which is why it is more likely to be installed. Seems that the test VMs
don't always have killall installed.
Run the MaxScale process with the maxscale user instead of the root user
to prevent any new files from being owned by a different user.
Cherry-picked the commit a06c122a5e050071589f724758d6bbd3d8d3f419 from
develop.
Due to the fact that both client connections and listeners use sessions in
2.3, the client_count tracking must be done inside the client DCB. In
addition to this, the max_connections check didn't take the current
pending connection into account which caused an off-by-one error.
This commit fixes the connection_limit test failure that was introduced by
commit 6306519e5e75575ba083ee2f0edfe7e624da5d26.
By incrementing the counters when the session is created, we know that the
counter will always be decremented correctly. This does cause the listener
session to be counted as an actual session but this is already present in
the statistics calculations and is something we have to live with in 2.3
This change also makes it possible to overshoot the connection count
limitation as the session creation is delayed until authentication
fails. Both of these problems are fixed in 2.4.
