HIVE-28265: Fix JDBC timeout message for hive.query.timeout.seconds

[ashniku]

What changes were proposed in this pull request?

hive.query.timeout.seconds is enforced correctly, but Beeline/JDBC reported Query timed out after 0 seconds when Statement.setQueryTimeout was not used.

This PR:

1. SQLOperation (HiveServer2)
   Before cancel(OperationState.TIMEDOUT), set a HiveSQLException whose message is Query timed out after seconds, using the effective operation timeout ( is the same value used to schedule the cancel). GetOperationStatus then exposes the right text via operationException.
   For async execution, do not call setOperationException from the background thread if the operation is already TIMEDOUT, so the timeout message is not overwritten.

2. HiveStatement (JDBC)
   On TIMEDOUT_STATE, prefer the server errorMessage. If it is missing or clearly wrong (contains after 0 seconds), build the client message from Statement query timeout or from the last SET hive.query.timeout.seconds=... value tracked on HiveConnection. SET is detected with a regex find() so assignments can appear inside a longer script (last match wins).

3. HiveConnection
   Stores the last parsed hive.query.timeout.seconds from a successful SET for use in the timeout message when needed.

4. Tests

==> testQueryTimeoutMessageUsesHiveConf: session SET hive.query.timeout.seconds=1s, no setQueryTimeout, slow query via existing SleepMsUDF — expects SQLTimeoutException and message not claiming after 0 seconds, and containing 1.
==> testQueryTimeout: same checks for the existing setQueryTimeout(1) path.

-->

Why are the changes needed?

Does this PR introduce any user-facing change?

How was this patch tested?

[InvisibleProgrammer]

Can you show us an example about the whole output that demonstrates the change?

I wonder if it is possible to get any number other than the timeout in the message. Like a timestamp or maybe a query id, host name, etc. Asserting to a single number in a string looks a little bit fragile to me.

[ashniku]

Introduced constant QUERY_TIMED_OUT_AFTER_1_SECONDS = "Query timed out after 1 seconds" with Javadoc that this is the full message from HS2 / client (no query id, host, timestamp in that string for these paths).
testQueryTimeout now uses assertEquals, expected value = that constant, with a failure message that repeats the example text.

[InvisibleProgrammer]

We know it is 1 sec. And we don't accept any other output in that case.
In my opinion, regex here can be a little bit overkill.

What about something like:

final String expectedMessage = "Query timed out after 1 seconds";
assertEquals("Message should reflect JDBC query timeout", expectedMesage, message);

[ashniku]

Removed isQueryTimedOutAfterOneSecondMessage (regex helper).
Positive assertions use assertEquals("…", QUERY_TIMED_OUT_AFTER_1_SECONDS, e.getMessage()) in both timeout-related tests.

[InvisibleProgrammer]

Considering the previous assertion, is that assertion possible at all?

[ashniku]

(assertFalse(… "after 0 seconds") after the positive check in testQueryTimeout — “is that even possible?”)

Changes

Removed assertFalse(..., e.getMessage().contains("after 0 seconds")) from testQueryTimeout.

[InvisibleProgrammer]

Is it possible having an exception with null value in a catch block?

[ashniku]

(assertNotNull(e) in catch (SQLTimeoutException e) — can e be null?)

Changes

Removed assertNotNull(e) from both SQLTimeoutException catch blocks in these tests.

[InvisibleProgrammer]

What is the benefits of putting the ticket number into assertions or comments?

[ashniku]

Dropped ticket id from assertion messages.
Kept HIVE-28265 and expected message behavior in testQueryTimeoutMessageUsesHiveConf Javadoc (and the constant / assertEquals text describes behavior without the ticket).

[InvisibleProgrammer]

Considering the previous assertion, is that assertion possible at all?

[ashniku]

Removed assertFalse(..., "after 0 seconds") from testQueryTimeoutMessageUsesHiveConf.

[InvisibleProgrammer]

Thinking out loud: I wonder if a connection can have concurrency issue: I mean, you can have multiple individual connections to Hive, but inside a connection itself, can we have multiple hive statements in parallel?
I have no such use case in my mind, but let me ping Ayush about this question.

@ayushtkn , what do you think?

[ayushtkn]

a single JDBC Connection can be shared across multiple threads, and it is entirely possible to have multiple HiveStatement objects executing concurrently on the same connection (which maps to a single session on the HS2 side).

via Beeline or so maybe not but In Hive Server 2 (HS2), a single JDBC Connection corresponds to a single HS2 Session. You can absolutely execute multiple queries concurrently within the same session by spawning multiple threads on the client side, each using a different HiveStatement created from that single HiveConnection.

[InvisibleProgrammer]

Thx

[InvisibleProgrammer]

Can we keep the getter..setter naming pattern?

[ashniku]

recordSessionQueryTimeoutFromSet(long) → setSessionQueryTimeoutSeconds(long)
getSessionQueryTimeoutSecondsTracked() → getSessionQueryTimeoutSeconds()
HiveStatement updated to call the new names.

[ashniku]

Please review my change

[ashniku]

@deniskuzZ could you please review and let me know,if I have missed any

[deniskuzZ]

I think the PR is overengineered on the client side. Once the server sends the authoritative HYT00 message, the whole HiveConnection.sessionQueryTimeoutSeconds machinery — the field/setter, applySessionQueryTimeoutFromJdbcUrl(), getSessionQueryTimeoutSeconds(), and resolveEffectiveTimeoutSecondsForMessage() — is redundant

I removed all of it and let the fallback be just the per-statement queryTimeout (which is all a pre-HYT00 server can meaningfully report). All four of your timeout tests still pass

Subject: [PATCH] patch
---
Index: itests/hive-unit/src/test/java/org/apache/hive/jdbc/TestJdbcDriver2.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/itests/hive-unit/src/test/java/org/apache/hive/jdbc/TestJdbcDriver2.java b/itests/hive-unit/src/test/java/org/apache/hive/jdbc/TestJdbcDriver2.java
--- a/itests/hive-unit/src/test/java/org/apache/hive/jdbc/TestJdbcDriver2.java	(revision 93c40e17851b3c12beee9ef711705621b85ccf66)
+++ b/itests/hive-unit/src/test/java/org/apache/hive/jdbc/TestJdbcDriver2.java	(date 1783328104714)
@@ -2785,9 +2785,9 @@
   /**
    * Variant of {@link #testQueryTimeoutFromSetStatement}: the {@code SET} is issued on a separate,
    * already-closed statement; the timed-out query runs on a brand-new statement with no
-   * {@link Statement#setQueryTimeout(int)} call. The tracked session timeout lives on the
-   * {@link HiveConnection}, so it persists across statement instances and must still drive the
-   * {@link SQLTimeoutException} message correctly.
+   * {@link Statement#setQueryTimeout(int)} call. The timeout lives on the HS2 session, so it
+   * persists across client statement instances and the server-supplied {@link SQLTimeoutException}
+   * message must still reflect it correctly.
    */
   @Test
   public void testQueryTimeoutMessagePersistedAcrossStatements() throws Exception {
@@ -2801,7 +2801,7 @@
     stmt2.execute("set hive.query.timeout.seconds=1s");
     stmt2.close();
 
-    // Brand-new statement, no setQueryTimeout() call – relies solely on the tracked session value
+    // Brand-new statement, no setQueryTimeout() call – relies solely on the HS2 session timeout
     Statement stmt = con.createStatement();
     System.err.println("Executing query (expecting timeout): ");
     try {
Index: jdbc/src/java/org/apache/hive/jdbc/HiveConnection.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/jdbc/src/java/org/apache/hive/jdbc/HiveConnection.java b/jdbc/src/java/org/apache/hive/jdbc/HiveConnection.java
--- a/jdbc/src/java/org/apache/hive/jdbc/HiveConnection.java	(revision 93c40e17851b3c12beee9ef711705621b85ccf66)
+++ b/jdbc/src/java/org/apache/hive/jdbc/HiveConnection.java	(date 1783328248965)
@@ -69,7 +69,6 @@
 import java.util.Optional;
 import java.util.Properties;
 import java.util.concurrent.Executor;
-import java.util.concurrent.TimeUnit;
 import java.util.concurrent.locks.ReentrantLock;
 import java.util.stream.Stream;
 
@@ -83,7 +82,6 @@
 
 import org.apache.commons.lang3.StringUtils;
 import org.apache.hadoop.hive.common.auth.HiveAuthUtils;
-import org.apache.hadoop.hive.conf.HiveConf;
 import org.apache.hadoop.hive.conf.HiveConf.ConfVars;
 import com.google.common.annotations.VisibleForTesting;
 import com.google.common.base.Preconditions;
@@ -165,13 +163,6 @@
  */
 public class HiveConnection implements java.sql.Connection {
   private static final Logger LOG = LoggerFactory.getLogger(HiveConnection.class);
-
-  /**
-   * Last effective {@code hive.query.timeout.seconds} in seconds, or {@code -1} if not yet set.
-   * Seeded from the JDBC URL at connect time; a JDBC {@link java.sql.Connection} may be shared
-   * across threads with concurrent {@link org.apache.hive.jdbc.HiveStatement}s on one HS2 session.
-   */
-  private volatile long sessionQueryTimeoutSeconds = -1L;
   private String jdbcUriString;
   private String host;
   private int port;
@@ -199,46 +190,6 @@
 
   public TCLIService.Iface getClient() { return client; }
 
-  /**
-   * Updates the tracked {@code hive.query.timeout.seconds} value (in seconds) on this connection.
-   * Called at connect time from the JDBC URL hive-conf map, and may be called again later if needed.
-   */
-  void setSessionQueryTimeoutSeconds(long seconds) {
-    sessionQueryTimeoutSeconds = seconds;
-  }
-
-  /**
-   * If the JDBC URL supplied {@code hive.query.timeout.seconds} (via the {@code ?hive_conf_list}
-   * segment), parses and stores the value so that {@link #getSessionQueryTimeoutSeconds()} can
-   * return it for timeout error messages. This runs once at connect time and does not affect the
-   * server-side configuration, which is applied separately in {@link #openSession()}.
-   */
-  private void applySessionQueryTimeoutFromJdbcUrl() {
-    Map<String, String> hiveConfs = connParams.getHiveConfs();
-    if (hiveConfs == null || hiveConfs.isEmpty()) {
-      return;
-    }
-    String raw = hiveConfs.get(ConfVars.HIVE_QUERY_TIMEOUT_SECONDS.varname);
-    if (StringUtils.isBlank(raw)) {
-      return;
-    }
-    try {
-      long sec = HiveConf.toTime(raw.trim(), TimeUnit.SECONDS, TimeUnit.SECONDS);
-      if (sec > 0) {
-        setSessionQueryTimeoutSeconds(sec);
-      }
-    } catch (Exception e) {
-      LOG.debug("Could not parse {} from JDBC URL: {}", ConfVars.HIVE_QUERY_TIMEOUT_SECONDS.varname, raw, e);
-    }
-  }
-
-  /**
-   * @return the tracked {@code hive.query.timeout.seconds} in seconds, or {@code -1} if not set
-   */
-  long getSessionQueryTimeoutSeconds() {
-    return sessionQueryTimeoutSeconds;
-  }
-
   /**
    * Get all direct HiveServer2 URLs from a ZooKeeper based HiveServer2 URL
    * @param zookeeperBasedHS2Url
@@ -381,7 +332,6 @@
     // hive_conf_list -> hiveConfMap
     // hive_var_list -> hiveVarMap
     sessConfMap = connParams.getSessionVars();
-    applySessionQueryTimeoutFromJdbcUrl();
     setupLoginTimeout();
     if (isKerberosAuthMode()) {
       // Ensure UserGroupInformation includes any authorized Kerberos principals.
Index: jdbc/src/java/org/apache/hive/jdbc/HiveStatement.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/jdbc/src/java/org/apache/hive/jdbc/HiveStatement.java b/jdbc/src/java/org/apache/hive/jdbc/HiveStatement.java
--- a/jdbc/src/java/org/apache/hive/jdbc/HiveStatement.java	(revision 93c40e17851b3c12beee9ef711705621b85ccf66)
+++ b/jdbc/src/java/org/apache/hive/jdbc/HiveStatement.java	(date 1783328875508)
@@ -399,43 +399,19 @@
   }
 
   /**
-   * Returns the timeout message for a {@code TIMEDOUT_STATE} response.
-   * Uses the server error message when the SQL state is {@code HYT00} ("timeout expired"),
-   * which indicates that the server set a precise message. Otherwise falls back to a
-   * locally derived message from {@link #setQueryTimeout(int)} or the URL-seeded
-   * {@code hive.query.timeout.seconds} value on the connection.
+   * Returns the timeout message for a {@code TIMEDOUT_STATE} response. The server is authoritative:
+   * when the SQL state is {@code HYT00} ("timeout expired") it has set a precise message that
+   * already reflects the effective {@code hive.query.timeout.seconds}, so it is used verbatim.
+   * Otherwise (e.g. an older server) falls back to the per-statement {@link #setQueryTimeout(int)}.
    */
   private String sqlTimeoutMessageForTimedOutState(String serverMessage, String sqlState) {
     if ("HYT00".equals(sqlState) && StringUtils.isNotBlank(serverMessage)) {
       return serverMessage;
     }
-    long effectiveSec = resolveEffectiveTimeoutSecondsForMessage();
-    if (effectiveSec > 0) {
-      return "Query timed out after " + effectiveSec + " seconds";
-    }
-    return "Query timed out";
-  }
-
-  private long resolveEffectiveTimeoutSecondsForMessage() {
     if (queryTimeout > 0) {
-      return queryTimeout;
-    }
-    long tracked = connection.getSessionQueryTimeoutSeconds();
-    if (tracked > 0) {
-      return tracked;
+      return "Query timed out after " + queryTimeout + " seconds";
     }
-    return 0L;
-  }
-
-  private SQLException sqlExceptionForCanceledState(TGetOperationStatusResp statusResp) {
-    final String errMsg = statusResp.getErrorMessage();
-    final String fullErrMsg;
-    if (errMsg == null || errMsg.isEmpty()) {
-      fullErrMsg = QUERY_CANCELLED_MESSAGE;
-    } else {
-      fullErrMsg = QUERY_CANCELLED_MESSAGE + " " + errMsg;
-    }
-    return new SQLException(fullErrMsg, "01000"); // SQLSTATE 01000 = warning
+    return "Query timed out";
   }
 
   /**
@@ -457,7 +433,11 @@
       isLogBeingGenerated = false;
       break;
     case CANCELED_STATE:
-      throw sqlExceptionForCanceledState(statusResp);
+      // 01000 -> warning
+      final String errMsg = statusResp.getErrorMessage();
+      final String fullErrMsg =
+          (errMsg == null || errMsg.isEmpty()) ? QUERY_CANCELLED_MESSAGE : QUERY_CANCELLED_MESSAGE + " " + errMsg;
+      throw new SQLException(fullErrMsg, "01000");
     case TIMEDOUT_STATE:
       throw new SQLTimeoutException(
           sqlTimeoutMessageForTimedOutState(statusResp.getErrorMessage(), statusResp.getSqlState()));
Index: service/src/java/org/apache/hive/service/cli/operation/SQLOperation.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/service/src/java/org/apache/hive/service/cli/operation/SQLOperation.java b/service/src/java/org/apache/hive/service/cli/operation/SQLOperation.java
--- a/service/src/java/org/apache/hive/service/cli/operation/SQLOperation.java	(revision 93c40e17851b3c12beee9ef711705621b85ccf66)
+++ b/service/src/java/org/apache/hive/service/cli/operation/SQLOperation.java	(date 1783328402146)
@@ -177,6 +177,12 @@
         timeoutExecutor = Executors.newSingleThreadScheduledExecutor();
         timeoutExecutor.schedule(() -> {
           try {
+            // The query may have already finished, failed, or been cancelled before this task
+            // fires (the executor is only shut down when the operation is closed). Skip in that
+            // case so we don't overwrite a real result/exception with a spurious timeout message.
+            if (getState().isTerminal()) {
+              return null;
+            }
             final String queryId = queryState.getQueryId();
             log.info("Query timed out after: {} seconds. Cancelling the execution now: {}", queryTimeout, queryId);
             setOperationException(new HiveSQLException(

[ashniku]

@deniskuzZ

Addressed the latest review feedback in the most recent push: removed the redundant sessionQueryTimeoutSeconds field from HiveConnection and now parse hive.query.timeout.seconds on demand from connParams.getHiveConfs() when building a client-side fallback message (the primary path remains the server HYT00 message from SQLOperation). Also reverted the out-of-scope sqlExceptionForCanceledState extraction in HiveStatement back to the original inline ternary for CANCELED_STATE, dropped the unrelated Jenkinsfile skipPublishingChecks change, and updated test Javadoc/comments to reflect that SET-based timeouts are covered by the HS2 timeout message rather than connection-level tracking.

CI passed. Final PR: server sets HYT00 with the correct timeout message in SQLOperation; JDBC client uses it verbatim with setQueryTimeout() as the only fallback. All client-side session timeout tracking removed per your feedback. Four timeout tests pass. Only incidental HiveConnection change is getRetryIntervalMillis() extraction for Sonar.

[ashniku]

@deniskuzZ could you please check

[deniskuzZ]

maybe simplify sqlTimeoutMessage() ?

[sonarqubecloud]

Quality Gate passed

Issues
9 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.2% Duplication on New Code

See analysis details on SonarQube Cloud

[deniskuzZ]

why do you use synchronized here? timeoutExecutor is single-threaded and i don't see we synchronize anywhere else

[deniskuzZ]

wonder if that doesn't make above state == OperationState.TIMEDOUT check redundant

[ashniku]

Removed the synchronized block — timeoutExecutor is single-threaded and we don’t synchronize elsewhere on this path; the isTerminal() check plus setOperationException() guard is enough.

Dropped the explicit TIMEDOUT check — it was redundant since TIMEDOUT is terminal and already covered by state.isTerminal() && state != OperationState.ERROR.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

[ashniku]

Updated Javadoc — the server HYT00 message reflects the effective operation timeout (min of session hive.query.timeout.seconds and setQueryTimeout()), not the session value alone

[ashniku]

sqlTimeoutMessageForTimedOutState() now accepts a server HYT00 message only when it does not contain the known-bad after 0 seconds placeholder; otherwise it falls back to the per-statement setQueryTimeout() message. Added TestHiveStatement.testIsUsableServerTimeoutMessage.