hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vaibhav Gumashta (JIRA)" <>
Subject [jira] [Commented] (HIVE-5217) Add long polling to asynchronous execution in HiveServer2
Date Wed, 06 Nov 2013 19:48:18 GMT


Vaibhav Gumashta commented on HIVE-5217:

[~cwsteinbach] Sure, let me rebase on the trunk. You can look at the patch here:,
but I can create a request on RB if you prefer that.

Actually the delay period only affects the async SQLOperation (and returns immediately if
the async call has the results) and doesn't change the blocking calls. Also, as far as I understand
the use case you are pointing to is for a cleanup type of operation, where we might want to
clean up the entire session based on whether the client is active or not. In that case, the
cleanup thread might end up checking the last active time of the session rather than the operation
state and based on whether it exceeds some threshold, delete the session from the server.

Moving the long polling logic to CLIService might involve changing the Operation API, which
I was trying to avoid until we get to a specific use case. But if you feel otherwise, I can
definitely make the change. 

Thanks for looking at the patch! 

> Add long polling to asynchronous execution in HiveServer2
> ---------------------------------------------------------
>                 Key: HIVE-5217
>                 URL:
>             Project: Hive
>          Issue Type: Improvement
>          Components: HiveServer2
>    Affects Versions: 0.13.0
>            Reporter: Vaibhav Gumashta
>            Assignee: Vaibhav Gumashta
>             Fix For: 0.13.0
>         Attachments: HIVE-5217.D12801.2.patch, HIVE-5217.D12801.3.patch, HIVE-5217.D12801.4.patch,
> [HIVE-4617|] provides support for async
execution in HS2. The client gets an operation handle which it can poll to check on the operation
status. However, the polling frequency is entirely left to the client which can be resource
inefficient. Long polling will solve this, by blocking the client request to check the operation
status for a configurable amount of time (a new HS2 config) if the data is not available,
but responding immediately if the data is available.

This message was sent by Atlassian JIRA

View raw message