Fix backend protocol command tracking

If a query was processed in the client protocol module when a prepared
statement was being executed by the backend module, the current command
would get overwritten. This caused a debug assertion in readwritesplit to
trigger as the result was neither a single packet nor a collected result.

The RCAP_TYPE_STMT_INPUT capability guarantees that a buffer contains a
complete packet. This information can be used to track the currently
executed command based on the buffer contents which allows asynchronicity
betweent the client and backend protocol. In practice this only comes in
play when routers queue queries for later execution.
This commit is contained in:
Markus Mäkelä
2017-10-07 23:17:10 +03:00
parent b8035a6047
commit 2ca050156f

View File

@ -377,9 +377,20 @@ mxs_auth_state_t handle_server_response(DCB *dcb, GWBUF *buffer)
static inline void prepare_for_write(DCB *dcb, GWBUF *buffer)
{
MySQLProtocol *proto = (MySQLProtocol*)dcb->protocol;
uint64_t capabilities = service_get_capabilities(dcb->session->service);
/** Copy the current command being executed to this backend */
if (dcb->session->client_dcb && dcb->session->client_dcb->protocol)
/**
* Copy the current command being executed to this backend. For statement
* based routers, this is tracked by using the current command being executed.
* For routers that stream data, the client protocol command tracking data
* is used which does not guarantee that the correct command is tracked if
* something queues commands internally.
*/
if (rcap_type_required(capabilities, RCAP_TYPE_STMT_INPUT))
{
proto->current_command = (mxs_mysql_cmd_t)MYSQL_GET_COMMAND(GWBUF_DATA(buffer));
}
else if (dcb->session->client_dcb && dcb->session->client_dcb->protocol)
{
MySQLProtocol *client_proto = (MySQLProtocol*)dcb->session->client_dcb->protocol;
proto->current_command = client_proto->current_command;