You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hive.apache.org by "Thejas M Nair (JIRA)" <ji...@apache.org> on 2016/04/08 20:01:25 UTC

[jira] [Comment Edited] (HIVE-6535) JDBC: async wait should happen during fetch for results

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

Thejas M Nair edited comment on HIVE-6535 at 4/8/16 6:01 PM:
-------------------------------------------------------------

More details on the issue in waiting in fetch results and returning immediately after compile in stmt.execute, based on discussion with Vaibhav -
 * There is no fetch results when the query being executed is not a select query. We could block on calls like getUpdateCount(), but not everyone calls that.
 * In such cases, the user might call execute() followed by another Statement function such as execute, or close. It is not clear if the user would expect the previous query to block on this call after the first execute. Should the next call return an error if the first execute fails ? - That is not an intuitive behavior.
 * Statement.execute() documentation says ,that it throws SQLTimeoutException - when the driver has determined that the timeout value that was specified by the setQueryTimeout method has been exceeded and has at least attempted to cancel the currently running Statement. This cannot be implemented execute is not blocking.
 * Statement.cancel documentation talks about creating a separate thread for cancelling, another place where the assumption that stmt.execute is blocking is called out.



was (Author: thejas):
More details on the issue in waiting in fetch results and returning immediately after compile in stmt.execute, based on discussion with Vaibhav -
 * There is no fetch results when the query being executed is not a select query. We could block on calls like getUpdateCount(), but not everyone calls that.
 * In such cases, the user might call execute() followed by another Statement function such as execute, or close or cancel. It is not clear if the user would expect the previous query to block on this call after the first execute. Should the next call return an error if the first execute fails ? - That is not an intuitive behavior.
 * Statement.execute() documentation says ,that it throws SQLTimeoutException - when the driver has determined that the timeout value that was specified by the setQueryTimeout method has been exceeded and has at least attempted to cancel the currently running Statement. This cannot be implemented execute is not blocking.
 * Statement.cancel documentation talks about creating a separate thread for cancelling, another place where the assumption that stmt.execute is blocking is called out.


> JDBC: async wait should happen during fetch for results
> -------------------------------------------------------
>
>                 Key: HIVE-6535
>                 URL: https://issues.apache.org/jira/browse/HIVE-6535
>             Project: Hive
>          Issue Type: Improvement
>          Components: HiveServer2, JDBC
>    Affects Versions: 0.14.0, 1.2.1, 2.0.0
>            Reporter: Thejas M Nair
>            Assignee: Vaibhav Gumashta
>         Attachments: HIVE-6535.1.patch, HIVE-6535.2.patch
>
>
> The hive jdbc client waits query completion during execute() call. It would be better to block in the jdbc for completion when the results are being fetched.
> This way the application using hive jdbc driver can do other tasks while asynchronous query execution is happening, until it needs to fetch the result set.
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)