| Bug #68278 | Enabling dumpQueriesOnException clobbers any MySQLTimeoutException being thrown | ||
|---|---|---|---|
| Submitted: | 5 Feb 2013 17:16 | Modified: | 2 Mar 2022 10:31 |
| Reporter: | Christopher Schultz | Email Updates: | |
| Status: | Can't repeat | Impact on me: | |
| Category: | Connector / J | Severity: | S3 (Non-critical) |
| Version: | 5.1.23 | OS: | Any |
| Assigned to: | Alexander Soklakov | CPU Architecture: | Any |
[5 Feb 2013 17:18]
Christopher Schultz
Test case that shows the difference in SQLException type (and stack trace) between dumped versus non-dumped queries
Attachment: MySQLTest.java (text/x-java-source), 1.55 KiB.
[22 Feb 2013 17:45]
Sveta Smirnova
Thank you for the report. Verified as described.
[2 Mar 2022 10:31]
Alexander Soklakov
Posted by developer: This bug is not reproducible with the latest Connector/J 8.0. Connector/J 5.1 series came to EOL on Feb 9th, 2021, see https://www.mysql.com/support/eol-notice.html, so this bug will not be fixed there.
Description: When a query time out is set (e.g. PreparedStatement.setQueryTimeout) and dumpQueriesOnException is set to 'true', a timing-out query throws a bare SQLException instead of a MySQLTimeoutException, so client code can't tell the difference without resorting to scanning the message's contents. Curiously, query-dumping only occurs when a real table is mentioned in the query so it was tough to track this one down using simple queries like "SELECT SLEEP(2)". I'll attach a test case. How to repeat: Run the test case. Suggested fix: ConnectionImpl has a method 'appendMessageToException' which replaces the existing exception with a new SQLException without attempting to match the original type: SQLException sqlExceptionWithNewMessage = SQLError.createSQLException(messageBuf .toString(), sqlState, vendorErrorCode, interceptor); If the original exception type can be used (e.g. by using reflection to call the common 3-arg constructor - reason, SQLState, vendorCode) then client code can reliably catch timeout events. Alternately, a vendor code and/or SQL state could be invented for "query timeout". Currently, the error code is 0 and the SQLState is null for these query timeout situations.