When packets were routed individually, the qualification for the
persistent pool was done before the current command was updated. In
addition to this, the previous commit doesn't seem like it can even build.
The statement tracking was given the same buffer multiple times when a
large packet was spread across multiple buffers when a router with
RCAP_TYPE_STMT_INPUT was present.
The command tracking packet processing is redundant for routers that
require RCAP_TYPE_STMT as the same processing is done later when the
buffer is split into packets and routed. By using the split packets, the
protocol module can simplify the command tracking by a great deal for most
routers.
Sending an error to the client allows the connector to show more
information to the user when the DCB is closed due to a reason internal to
MaxScale.
The error message states that the connection was killed by MaxScale to
distinct it from the error sent by the server. The error number and SQL
state are still the same as both errors should be treated the same way.
This builds on commit 1287b0e595a5f99026f66df7eeaef091b8ffc774 and cleans
up the original code. This fixes a bug introduced in the aforementioned
commit and cleans up the code.
The authentication code assumed that the initial request only had
authentication related data. This is not true if the client library
predicts that the authentication will succeed and it sends a query right
after it sends the authentication data.
When a session is being closed in a controlled manner, i.e. a COM_QUIT is
received from the client, it is possible to deduce from this fact that the
backend connections are very likely to be idle. This can be used as an
additional qualification that must be met by all connections before they
can be candidates for connection pooling.
This assumption will not hold with batched and asynchronous queries. In
this case it is possible that the COM_QUIT is received from the client
before even the first result from the backend is read. For this to work,
the protocol module would need to track the number and state of expected
responses.
If a connection has not been fully established (i.e. authentication has
been completed) then it should not be considered as a connection pool
candidate.
Transaction boundaries can now be detected using regexes.
All else being equal, it gives a 10% performance improvement
compared to qc-based detection.
In a subsequent change, mysql_client.c will be modified to use
qc_get_trx_type_mask() instead of qc_get_type_mask().
Currently the use of regex matching is turned on using an
environment variable. That will change.
The client protocol module can resolve whether a password was used based
on the information the authenticators gather before authentication is
done. It uses the authentication token length as the basis on which it
makes the decision.
Currently the only situation where a user needs to be authenticated after
the initial authentication is when a COM_CHANGE_USER is being
executed. This was previously handled by directly calling a function in
the MySQLAuth authenticator.
The new entry in the API of the authenticators is very specific to MySQL
and should be reviewed once other protocols are added.
Removed unused spinlocks from DCBs, sessions and the MySQL protocol
structs. They were used in a context where only one thread has access to
the structure.
Removed unused member variables from DCBs.
The transaction tracking now flags the transaction as open even when a
COMMIT/ROLLBACK is received. The next statement after the transaction is
closed resets the transaction state to inactive. This means that the end
of the transaction belongs in the transaction.
This allows all statements that belong to a transaction to be detected
with the transaction tracking functions provided by the core. With this,
the routing modules should have an easier time handling transactions.
When the transaction ends, it's good to know what type of a transaction
just ended. Currently, this will be used by readwritesplit to detect when
a read-only transaction ends.
All modules now declare a name for the module. This is name is added as a
prefix to all messages logged by a module. The prefix should help
determine which part of the system logs a message.
The MXS_MODULDE object now contains optinal pointers for functions
to be called att process and thread startup and shutdown. Since the
functions were added to the end, strictly speaking, all structures
would not have needed to have been modified, but better to be
explicit. In a subsequent change, these will be called.
C++ does not support flexible arrays, so for the time being C++
modules are restricted to 10 parameters. Better approach is to
factor out the parameters to a separate array and then just store
a pointer to that array in MXS_MODULE.
The MODULE_INFO is now the main object which is used by modules to convey
information to the MaxScale core. The MXS_MODULE name is more apt as it
now contains the actual module definition.
The old MODULES structure was moved into load_utils.c as an internal
implementation and was renamed so that it is not confused with the new
MODULE structure.
The modules are now declared with a common macro. This allows future
additions to the module loading process while also making the loaded
symbol name a constant.
This allows modules to only expose one entry point with a consistent
signature. In the future, this could be used to implement declarations of
module parameters.
The transaction state only reflects explicitly started transactions.
Thus, by looking at the autocommit mode and the transaction state a
component can figure out whether the current statement will be committed
or not.
The transaction state must be updated after a buffer has been split
into buffer containing individual packets.
NOTE: The actual updating of the transaction state and the autocommit
mode is currently wrong, but will be updated in a subsequent change.
This tracks only what is explicitly set. That is, if autocommit
has been set true then, even if a transaction is started, autocommit
will not be set false.
That is, a user of the session autocommit and transaction states
need to be aware of their semantics. If a transaction is active,
then the state of autocommit is irrelevant.
When a MySQL SSL connection is made, the first packet from the client will
contain the SSLRequest packet. This packet is a truncated normal auth
packet and the real auth packet will be sent after SSL has been
established.
The MySQLClient protocol should read the client information for SSL
connections after SSL has been established.
