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).
The hard limit of 10 seconds is too strict when taking into account the
fact that infinite refreshes was possible before the bug was fixed. This
also makes testing a lot easier where rapid reloads are necessary.
Certain MariaDB connectors will use the direct execution for batching
COM_STMT_PREPARE and COM_STMT_EXECUTE execution without waiting for the
COM_STMT_PREPARE to complete. In these cases the COM_STMT_EXECUTE (and
other COM_STMT commands as well) will use the special ID 0xffffffff. When
this is detected, it should be substituted with the ID of the latest
statement that was prepared.
If an error is generated while a COM_CHANGE_USER is being done, it would
always use the sequence number 1. To properly handle this case and send
the correct sequence number, the COM_CHANGE_USER progress needs to be
tracked at the session level.
The information needs to be shared between the backend and client
protocols as the final OK to the COM_CHANGE_USER, with the sequence number
3, is the one that the backend server returns. Only after this response
has been received and routed to the client can the COM_CHANGE_USER
processing stop.
If a server fails mid-resultset, there's not a lot we can do to recover
the situation. A few cases could be handled (e.g. generate an ERR if the
resultset has proceeded to the row processing stage) but these fall
outside the scope of the original issue.
If a COM_STMT_EXECUTE has no metadata in it and it has more than one
parameter, it must be routed to the same backend where the previous
COM_STMT_EXECUTE with the same ID was routed to. This prevents MDEV-19811
that is triggered by MaxScale routing the queries to different backends.
Added range-erase method to mxs::Buffer. This makes it easier to modify
the contents of mxs::Buffer.
The intended use-case for now is to erase unexpected trailing ERR packets
from resultsets.
The name of the object (i.e. the section name from the configuration
file), is now stored in the configuration object for that object.
That way, more contextual and hence morfe user friendly errors and
warnings can be generated.
Rename config::Configuration::configure() to
config::Configuration::post_configure(). Latter name makes it
unambiguously clear at what point the function is called.
The functionality is more a part of the provider than the context so it
should be defined in it. It also doesn't use any parts of the SSLContext
which makes it somewhat more clear that it doesn't belong there.
Changes to SSL configurations is expected to be rare which allows them to
be made into immutable objects once created. This is an acceptable
compromise between performance and usability.
The header depended on ssl.hh to include the OpenSSL headers even though
it used OpenSSL types. By fixing these dependencies the ssl.h header can
now freely include the rworker_local type which removes the need for the
hidden implementation of SSLProvider.
The class is intended to be inherited by objects that need an SSL context
and a configuration. In practice this will be servers and listeners.
The SSLContext is stored in a rworker_local shared_ptr that makes it
possible to update safely. As the copying is always done behind a lock the
cached local value always holds a valid SSLContext instance for the
duration of all function calls.
Using the pImpl idiom, the routingworker.hh header is not exposed in the
ssl.hh header. This allows the SSLProvider class to be inherited more
easily.
