drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kkhatua <...@git.apache.org>
Subject [GitHub] drill issue #858: DRILL-3640: Support JDBC Statement.setQueryTimeout(int)
Date Fri, 30 Jun 2017 20:34:20 GMT
Github user kkhatua commented on the issue:

    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 infrastructure@apache.org or file a JIRA ticket
with INFRA.

View raw message