[ 
https://issues.apache.org/jira/browse/DRILL-3640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16242719#comment-16242719
 ] 

ASF GitHub Bot commented on DRILL-3640:
---------------------------------------

Github user laurentgo commented on a diff in the pull request:

    https://github.com/apache/drill/pull/1024#discussion_r149477955
  
    --- Diff: 
exec/jdbc/src/main/java/org/apache/drill/jdbc/impl/DrillCursor.java ---
    @@ -376,6 +415,19 @@ synchronized void cleanup() {
         currentBatchHolder.clear();
       }
     
    +  //Set the cursor's timeout in seconds
    --- End diff --
    
    you just need to get the value when the query is executed (in DrillCursor) 
once to make sure the timeout doesn't change (that and StopWatch being managed 
by DrillCursor too.
    
    Also, it is subject to interpretation but it seems the intent of the API is 
to time bound how much time it takes the query to complete. I'm not sure it is 
necessary to make the extra work of having a slow client reading the result set 
data although all data has already been read by the driver from the server (and 
from the server point of view, the query is completed).


> Drill JDBC driver support Statement.setQueryTimeout(int)
> --------------------------------------------------------
>
>                 Key: DRILL-3640
>                 URL: https://issues.apache.org/jira/browse/DRILL-3640
>             Project: Apache Drill
>          Issue Type: New Feature
>          Components: Client - JDBC
>    Affects Versions: 1.2.0
>            Reporter: Chun Chang
>            Assignee: Kunal Khatua
>             Fix For: 1.12.0
>
>
> It would be nice if we have this implemented. Run away queries can be 
> automatically canceled by setting the timeout. 
> java.sql.SQLFeatureNotSupportedException: Setting network timeout is not 
> supported.
>       at 
> org.apache.drill.jdbc.impl.DrillStatementImpl.setQueryTimeout(DrillStatementImpl.java:152)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to