Github user kkhatua commented on a diff in the pull request:
https://github.com/apache/drill/pull/1024#discussion_r150160362
--- Diff:
exec/jdbc/src/main/java/org/apache/drill/jdbc/impl/DrillResultSetImpl.java ---
@@ -96,6 +105,14 @@ private void throwIfClosed() throws
AlreadyClosedSqlException,
throw new AlreadyClosedSqlException( "ResultSet is already
closed." );
}
}
+
+ //Implicit check for whether timeout is set
+ if (elapsedTimer != null) {
--- End diff --
Ok, so I think I see how you've been trying to help me test the server side
timeout.
You are hoping to have a unit test force the awaiteFirstMessage() throw the
exception by preventing the server from sending back any batch of data, since
the sample test data doesn't allow for any query to run sufficiently long. All
the current tests I've added essentially have already delivered the data from
the 'Drill Server' to the 'DrillClient', but the application downstream has not
consumed it.
Your suggestion of putting a `pause` before the `execute()` call got me
thinking that the timer had already begun after Statement initialization. My
understanding now is that you're simply asking to block any SCREEN operator
from sending back any batches. So, the DrillCursor should time out waiting for
the first batch. In fact, I'm thinking that I don't even need a pause. The
DrillCursor awaits all the time for something from the SCREEN operator that
never comes and eventually times out.
However, since the control injection is essentially applying to the
Connection (`alter session ...`, any other unit tests in parallel execution on
the same connection, would be affected by this. So, I would need to also undo
this at the end of the test, if the connection is reused. Or fork off a
connection exclusively for this.
Was that what you've been suggesting all along?
---
