[jdbc-v1] Statement.cancel() throws NOTHING_TO_KILL (785) on ClickHouse 26.11+ when the query is already finished

Abierto
  • ¿Algo no está bien?
#3,273 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
67/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
clickhouse, java
Área
backend, database

Línea de trabajo

Read clickhouse-jdbc/src/main/java/com/clickhouse/jdbc/internal/ClickHouseStatementImpl.java, especially cancel() and its error handling around KILL QUERY. Compare the v1 behavior with the jdbc-v2 fix in #3271, then add coverage for cancel() after a query has finished and for cancellation of a running query. Done means error 785 is ignored while other errors still propagate and running queries can still be cancelled.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

area:general bug jdbc-v1 wontfix

Description

In the legacy v1 JDBC driver (clickhouse.jdbc.v1=true), Statement.cancel() throws SQLException (error code 785, NOTHING_TO_KILL) on ClickHouse 26.11+ when the statement has no running query. This is the usual case when cancel() races with a query that has just finished.

Cause on the server side: ClickHouse 26.11 enables kill_throw_if_noop by default (ClickHouse/ClickHouse#125968, "Backward Incompatible Change"). A local KILL QUERY that matches no running query now fails with code 785. Before 26.11 the same statement returned an empty result.

This is the v1 equivalent of #3264 (jdbc-v2). The jdbc-v2 fix is in #3271. That PR says that the v1 driver is out of scope.

Steps to reproduce
  1. Start ClickHouse 26.11 (clickhouse/clickhouse-server:head, tested on 26.11.1.888).
  2. Connect with the v1 driver (clickhouse.jdbc.v1=true).
  3. Run a query, read the result to the end, then call stmt.cancel().
Error Log or Exception StackTrace
java.sql.SQLException: Code: 785. DB::Exception: No query to kill. (NOTHING_TO_KILL) (version 26.11.1.888 (official build))
  errorCode=785 sqlState=07000

Results of the same program on two servers (compress=0 because of #3107):

Case 26.9.1.1629 26.11.1.888
cancel() on a statement that never ran a query OK OK
cancel() after executeQuery("SELECT 1") is fully read OK SQLException 785
cancel() after executeUpdate("DROP TABLE IF EXISTS ...") OK SQLException 785
cancel() while a long query runs OK (query killed) OK (query killed)

The server alone, without the client:

$ curl -u default:... http://localhost:8123/ --data-binary "KILL QUERY WHERE query_id='nope'"
Code: 785. DB::Exception: No query to kill. (NOTHING_TO_KILL) (version 26.11.1.888 (official build))
$ curl -u default:... "http://localhost:8123/?kill_throw_if_noop=0" --data-binary "KILL QUERY WHERE query_id='nope'"
(empty result, HTTP 200)
Expected Behaviour

cancel() does not throw when there is no running query to cancel. There is nothing to cancel, so the application should not get an error. This is the behavior on servers before 26.11, and the behavior that #3271 gives jdbc-v2.

Root cause: clickhouse-jdbc/src/main/java/com/clickhouse/jdbc/internal/ClickHouseStatementImpl.java (main @ 771b8bcca):

  • line 360: queryId is set for each query and is not cleared when the query completes. So cancel() after a finished query still sends KILL QUERY WHERE query_id='<id>' (line 675).
  • lines 684-685: catch (Exception e) { throw SqlExceptionUtils.handle(e.getCause()); } rethrows every server error, including 785.

Suggested fix: in cancel(), ignore a server error with code 785 (NOTHING_TO_KILL) and write a debug log. Keep these behaviors:

  • Other KILL QUERY errors are still thrown.
  • cancel() of a running query still kills it.
  • The transaction abort after the KILL QUERY (request.getTransaction().abort()) still runs when 785 is ignored. Now the throw skips it (code reading).

Do not send kill_throw_if_noop=0: servers before 26.10 reject the unknown setting.

Code Example
Properties p = new Properties();
p.setProperty("user", "default");
p.setProperty("password", "...");
String url = "jdbc:clickhouse://localhost:8123/default?clickhouse.jdbc.v1=true&compress=0";
try (Connection conn = new com.clickhouse.jdbc.ClickHouseDriver().connect(url, p);
     Statement stmt = conn.createStatement()) {
    try (ResultSet rs = stmt.executeQuery("SELECT 1")) {
        while (rs.next()) { }
    }
    stmt.cancel(); // 26.11+: SQLException code 785; 26.9: no error
}
Configuration
Client Configuration
// URL: jdbc:clickhouse://<host>:8123/default?clickhouse.jdbc.v1=true&compress=0
// compress=0 only avoids #3107; it has no effect on this bug.
Environment
  • Cloud
  • Client version: main @ 771b8bcca (0.12.0-rc1-SNAPSHOT), clickhouse-jdbc module
  • Language version: Java 17
  • OS: Linux (Docker)
ClickHouse Server
  • ClickHouse Server version: 26.11.1.888 (fails), 26.9.1.1629 (works)
  • ClickHouse Server non-default settings, if any: none (kill_throw_if_noop is 1 by default in 26.11)
  • CREATE TABLE statements for tables involved: none

Found by automated analysis (Polyglot AI) while working on #3264 (jdbc-v2). Verified against live 26.11 and 26.9 servers, not by code reading only.

Lenguaje dominante
Java
Estrellas
1.6k
Forks
649
Merge medio
1 d 20 h
PR fusionados (30 d)
39

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ClickHouse/clickhouse-java

Todos los issues de ClickHouse/clickhouse-java

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.