Mailing-List: contact dev-help@drill.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@drill.apache.org
From: kkhatua <git@git.apache.org>
To: dev@drill.apache.org
Reply-To: dev@drill.apache.org
References: <git-pr-858-drill@git.apache.org>
In-Reply-To: <git-pr-858-drill@git.apache.org>
Subject: [GitHub] drill issue #858: DRILL-3640: Support JDBC Statement.setQueryTimeout(int)
Content-Type: text/plain
Message-Id: <20170630203420.7C6B7DFE8B@git1-us-west.apache.org>
Date: Fri, 30 Jun 2017 20:34:20 +0000 (UTC)
archived-at: Fri, 30 Jun 2017 20:34:22 -0000

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