hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Amruth S (JIRA)" <>
Subject [jira] [Commented] (HIVE-18338) [Client, JDBC] Expose async interface through hive JDBC.
Date Thu, 28 Dec 2017 16:56:00 GMT


Amruth S commented on HIVE-18338:

[~ashutoshc]/[~ngangam]/[~thejas]/[~vgumashta], Can one of you guys kindly review this?

> [Client, JDBC] Expose async interface through hive JDBC.
> --------------------------------------------------------
>                 Key: HIVE-18338
>                 URL:
>             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

View raw message