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]

@InvisibleProgrammer could you please review if you are back from the vacation

[InvisibleProgrammer]

What is the value of this change?

Let's see, for example the existing test case, testURLWithFetchSize. Is it required having the timeout set to 1 seconds?

[ashniku]

@InvisibleProgrammer The old assertNotNull(e) didn’t validate the message. HIVE-28265 fixes cases where the message incorrectly said “after 0 seconds” while the real limit was 1 second. We set the limit to 1s in both tests (setQueryTimeout(1) vs SET hive.query.timeout.seconds=1s) and assert the message starts with Query timed out after 1 seconds and does not contain after 0 seconds. The 1 is the configured timeout, not an arbitrary magic number—if we used 2s, we’d assert 2 seconds. testURLWithFetchSize is a different feature (URL fetchSize); the analogy is only “set config → assert behavior.”

[ashniku]

I have commited new one.The new test testURLWithHiveQueryTimeoutSeconds is explicitly a 1 second case:

URL — it opens the connection with
getConnection(testDbName, "hive.query.timeout.seconds=1")
so the effective limit is 1 second.

Assertion — it calls assertTimeoutMessageShowsOneSecond, which requires the message to start with
Query timed out after 1 seconds
(the same constant as testQueryTimeout / testQueryTimeoutMessageUsesHiveConf).

So it’s aligned with the other 1s timeout tests, just with the limit coming from the JDBC URL query instead of setQueryTimeout(1) or SET hive.query.timeout.seconds=1s.

[ashniku]

@InvisibleProgrammer could you please check when free and suggest?

[InvisibleProgrammer]

Honestly, I have doubts about the change itself so currently I'm trying to reproduce the original issue.

The regex way of handling the set hive.query.timeout.seconds statement: in general, set statements are modifying variables that Hive already loads into a HiveConf object. The way of having a regex and checking every single statement makes me suspicious. I don't really get why we should introduce a new way of receiving set commands for one specific command. I more wonder about an other approach, like letting the current value of the setting for the statement/connection or getting a proper exception message at the right way from TGetOperationStatusResp.

On overall, I don't want to accept that the only way to pass a hive config value for a connection (or the effect of this value) is by checking all the statements that the user executed one-by-one.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

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

See analysis details on SonarQube Cloud

[InvisibleProgrammer]

I wonder, how this solution behaves with a test case when we have a single connection and we execute multiple statements, one-by-one?

Example test case:

  @Test
  public void testQueryTimeout() throws Exception {
    String udfName = SleepMsUDF.class.getName();
    Statement stmt1 = con.createStatement();
    stmt1.execute("create temporary function sleepMsUDF as '" + udfName + "'");
    stmt1.close();
    Statement stmt2 = con.createStatement();
    stmt2.execute("set hive.query.timeout.seconds=1s");
    stmt2.close();
    Statement stmt = con.createStatement();

    System.err.println("Executing query: ");
    try {
      // The test table has 500 rows, so total query time should be ~ 2500ms
      stmt.executeQuery("select sleepMsUDF(t1.under_col, 5) as u0, t1.under_col as u1, "
          + "t2.under_col as u2 from " + tableName + " t1 join " + tableName
          + " t2 on t1.under_col = t2.under_col");
      fail("Expecting SQLTimeoutException");
    } catch (SQLTimeoutException e) {
      assertNotNull(e);
      System.err.println(e.toString());
      assertEquals("Query timed out after 1 seconds", e.getMessage());
    } catch (SQLException e) {
      fail("Expecting SQLTimeoutException, but got SQLException: " + e);
      e.printStackTrace();
    }

    // Test a query where timeout does not kick in. Set it to 5s;
    // show tables should be faster than that
    stmt.setQueryTimeout(5);
    try {
      stmt.executeQuery("show tables");
    } catch (SQLException e) {
      fail("Unexpected SQLException: " + e);
      e.printStackTrace();
    }
    stmt.close();
  }