[
https://issues.apache.org/jira/browse/HIVE-18338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amruth S updated HIVE-18338:
----------------------------
Description:
Lot of users are struggling and rewriting a lot of boiler plate over thrift to
get pure asynchronous capability.
The idea is to expose operation handle, so that clients can persist it and
later can latch on to the same execution.
*Problem statement*
Hive JDBC currently exposes 2 methods related to asynchronous execution
*executeAsync()* - to trigger a query execution and return immediately.
*waitForOperationToComplete()* - which waits till the current execution is
complete *blocking the user thread*.
This has one problem
If the client process goes down, there is no way to resume queries although
hive server is completely asynchronous.
*Proposal*
If operation handle could be exposed, we can latch on to an active execution of
a query.
*Code changes*
Operation handle is exposed. So client can keep a copy.
latchSync() and latchAsync() methods take an operation handle and try to latch
on to the current execution in hive server if present
was:
Lot of users are struggling and rewriting a lot of boiler plate over thrift to
get pure asynchronous capability.
The idea is to expose operation handle, so that clients can persist it and
later can latch on to the same execution.
Let me know your ideas around this. We have solved this already at our org by
tweaking HiveStatement.java.
> [Client, JDBC] Expose async interface through hive JDBC.
> --------------------------------------------------------
>
> Key: HIVE-18338
> URL: https://issues.apache.org/jira/browse/HIVE-18338
> Project: Hive
> Issue Type: Improvement
> Components: Clients, JDBC
> Affects Versions: 2.3.2
> Reporter: Amruth S
> Assignee: Amruth S
> Priority: Minor
> Labels: pull-request-available
> Attachments: HIVE-18338.patch, HIVE-18338.patch.1,
> HIVE-18338.patch.2, HIVE-18338.patch.3
>
>
> Lot of users are struggling and rewriting a lot of boiler plate over thrift
> to get pure asynchronous capability.
> The idea is to expose operation handle, so that clients can persist it and
> later can latch on to the same execution.
> *Problem statement*
> Hive JDBC currently exposes 2 methods related to asynchronous execution
> *executeAsync()* - to trigger a query execution and return immediately.
> *waitForOperationToComplete()* - which waits till the current execution is
> complete *blocking the user thread*.
> This has one problem
> If the client process goes down, there is no way to resume queries although
> hive server is completely asynchronous.
> *Proposal*
> If operation handle could be exposed, we can latch on to an active execution
> of a query.
> *Code changes*
> Operation handle is exposed. So client can keep a copy.
> latchSync() and latchAsync() methods take an operation handle and try to
> latch on to the current execution in hive server if present
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
