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

Aperta
  • Qualcosa non va?
#3,273 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
67/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
clickhouse, java
Ambito
backend, database

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Java
Stelle
1.6k
Fork
649
Merge medio
1g 20h
PR unite (30g)
39

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ClickHouse/clickhouse-java

Tutte le issue di ClickHouse/clickhouse-java

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.