Mysql Connector/J Is Not Parsing The SessionStateChanges From The OK_Packet Correctly (Doc ID 2973218.1)

Last updated on SEPTEMBER 08, 2023

Applies to:

Symptoms

On : MySQL 8.0 version, Connector/J and JDBC

ACTUAL BEHAVIOR
---------------
Mysql Connector/J is not parsing the sessionStateChanges from the OK_Packet correctly.

Mysql server version: 8.0.32
Connector/J version: 8.0.31

What was observed:

When an update query is issued to the server by the connector, we are inspecting the sessionStateChanges for the GTIDs, what we expect is a an object with type=3, representing the GTID sessionState and a value equal to the GTID value, what we observe is a type of unknown values 53,55,57,... and a value that looks like a GTID this is an example fe651-e8a6-11ed-b0c1-5254006badde:358705lts.

Investigation:

Looking into the info field extracted from the OK_Packet in the debugger it looks something like this, (Rows matched: 1 Changed: 1 Warnings: 01/ when the correct value should be Rows matched: 1 Changed: 1 Warnings: 0. Inspecting the protocol specification for the OK_Packet and the byte array returned from the server, it seems that the info field is a LengthEncoded string, however by looking into the source code for Connector/J it seems that it is parsing the field as a zero terminated string. This wrong parsing causes the connector to read part of what is supposed to be a the GTID into the info field.

Link to the Connector/J source where the bug exists: https://github.com/mysql/mysql-connector-j/blob/7ff2161da3899f379fb3171b6538b191b1c5c7e2/src/main/protocol-impl/java/com/mysql/cj/protocol/a/result/OkPacket.java#L62

Changes

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.