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

Ouverte
  • Quelque chose ne va pas ?
#3,273 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
67/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
clickhouse, java
Domaine
backend, database

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Java
Étoiles
1.6k
Forks
649
Merge moyen
1 j 20 h
PR mergées (30 j)
39

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de ClickHouse/clickhouse-java

Toutes les issues de ClickHouse/clickhouse-java

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.