Github user kkhatua commented on the issue:
https://github.com/apache/drill/pull/858
Wouldn't a query cancellation automatically interrupt those potentially
blocking operations? I'm simply looking up whether the trigger was a timeout
DrillStatement.isTimedOut() to decide if the returning exception is a
SqlTimeoutExcp.
The extra thread (though mostly sleeping) didn't seem like a huge cost
considering that the timeout is at the granularity of seconds.
I ran a small custom JDBC client application to test this theory. Running
longevity and concurrency testing worked well when testing for timeouts. For
timeouts as low as 1 second for queries that needed to do lot of back end
processing before returning rows much later (like a massive join), I noticed
that we caught underlying exceptions as the timeouts during the 'executeQuery'
call itself. If I were to not go the route of issuing a Statement.cancel() but
relying primarily on the DrillCursor, unless I put in some mechanism of
constantly polling for the out-of-time state of the clock. I think then I also
need to cancel then cancel all operations from the level of the DrillCursor in
both directions (up to the Statement and down to the fragments). All this
versus issuing a Statement.cancel() that effectively cancels all the operations
down to the fragment level.
I am now wondering whether I missied a corner case which will be addressed
by doing the timeout in the DrillCursor?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
