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:
MySQL Connectors - Version 8.0 and laterInformation in this document applies to any platform.
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
To view full details, sign in with your My Oracle Support account. |
|
Don't have a My Oracle Support account? Click to get started! |
In this Document
Symptoms |
Changes |
Cause |
Solution |
References |