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

Aberta
  • Algo errado?
#3,273 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
67/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
clickhouse, java
Domínio
backend, database

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Java
Estrelas
1.6k
Forks
649
Merge médio
1d 20h
PRs com merge (30d)
39

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de ClickHouse/clickhouse-java

Todas as issues de ClickHouse/clickhouse-java

Issues semelhantes

Mais issues de Java

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.