apache/shardingsphere · error · SQLFeatureNotSupportedException

getClientInfo name

Error message

getClientInfo name

What it means

ShardingSphere's JDBC driver does not implement the java.sql.Connection method getClientInfo name (reading a single named JDBC 4 client info property from the connection). The abstract base class AbstractUnsupportedOperationConnection, which ShardingSphereConnection extends, overrides it as final and unconditionally throws SQLFeatureNotSupportedException. ShardingSphere does not store per-connection client info, so the name-based getter always throws. The exception is thrown the moment the method is invoked on any connection produced by the ShardingSphere Driver.

Source

Thrown at jdbc/src/main/java/org/apache/shardingsphere/driver/jdbc/unsupported/AbstractUnsupportedOperationConnection.java:124

    
    @Override
    public final SQLXML createSQLXML() throws SQLException {
        throw new SQLFeatureNotSupportedException("createSQLXML");
    }
    
    @Override
    public final Struct createStruct(final String typeName, final Object[] attributes) throws SQLException {
        throw new SQLFeatureNotSupportedException("createStruct");
    }
    
    @Override
    public final Properties getClientInfo() throws SQLException {
        throw new SQLFeatureNotSupportedException("getClientInfo");
    }
    
    @Override
    public final String getClientInfo(final String name) throws SQLException {
        throw new SQLFeatureNotSupportedException("getClientInfo name");
    }
    
    @Override
    public final void setClientInfo(final String name, final String value) {
        throw new UnsupportedSQLOperationException("setClientInfo name value");
    }
    
    @Override
    public final void setClientInfo(final Properties props) {
        throw new UnsupportedSQLOperationException("setClientInfo properties");
    }
}

View on GitHub (pinned to e952770a21)

Solutions

  1. Guard the call: catch SQLFeatureNotSupportedException and treat client info as unavailable, or check connection.getMetaData().getClientInfoProperties() emptiness first.
  2. Move per-request correlation data to MDC/ThreadLocal-based tracing instead of JDBC client info.
  3. Unwrap the native connection only if the backend driver itself was configured with client info outside ShardingSphere.
Defensive patterns

Strategy: try-catch

Validate before calling

boolean supportsOp = false;
try {
    connection.getMetaData(); // connection is alive
    // JDBC has no capability flag for individual methods; probe once per JVM:
    supportsOp = probeSupport(connection); // reflective/one-time guarded call
} catch (final SQLException ignored) {
}
// Simpler and recommended: capability-check by driver URL
boolean isShardingSphere = url.startsWith("jdbc:shardingsphere:");
if (isShardingSphere) {
    // skip the unsupported call, use the alternative API path
}

Try / catch

try {
    connection.getClientInfo(/* args */);
} catch (final SQLFeatureNotSupportedException e) {
    // expected on ShardingSphere connections: fall back to supported API
    log.debug("Driver does not support getClientInfo name, using fallback", e);
}

Prevention

When it happens

Trigger: Calling Connection.getClientInfo(name) with any property name on a ShardingSphere connection.

Common situations: APM/monitoring agents reading specific markers (e.g. 'comment' or vendor tags like ApplicationName); pool request-context propagation reading a per-request property.

Related errors

AI-assisted analysis of apache/shardingsphere@e952770a21 (2026-08-14). Data as JSON: /api/errors/b9d915fed9978ac3. Report an issue: GitHub.