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.
The default database was not exposed in the warning that was logged when
authentication failed. The authentication uses the username, host and the
default database to find the user entry and the lack of the default
database made it hard to know for sure which user entry a client should've
matched against.
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.
This causes the connection failure to be counted as an authentication
failure instead of a connection error. The former never causes the host to
be blocked which effectively solves the problem for most cases. The only
case where this would not work is where the network buffer for a backend
DCB is full right after the connection is created.
The FakeEventTask called the actual DCB handler with a fake task but it
didn't set the fake event flag. This caused KILL queries to be treated as
if they were network errors.
