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.
When a temporary table is created with a multi-statement query, it won't
be detected by MaxScale.
Also removed the wrong limitations section from the document.
The password values are now masked with asterisks. This tells whether a
password is set or not but it does not expose any information about the
password itself.
When a temporary table is created with a multi-statement query, it won't
be detected by MaxScale.
Also removed the wrong limitations section from the document.
We do not build RHEL packageas, but create RHEL repos as symlinks
to CentOS repos. For RHEL8 was an expection intruduced, because
CentOS 8 was not available at the time when RHEL8 was released.
Now CentOS 8 is also available, switching to CentOS 8 image.
The events are similar to normal query events except that they have an
extra 13 bytes of static data. This data is of no relevance to Maxscale
and thus can be ignored. This also allows the reuse of the same query
event code for execute load query events.
It appears that rollback errors are possible outside of
transactions. Since this was not something we expected to see, logging it
as an error allows us to see why this happens in production deployments.
The errors that are ignored by readwritesplit are now stored as the
current close reason in the Backend. This allows the information about the
error to be retained and it can be used later in the error handler to
display the true reason why the connection was closed.
