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

Vaibhav Gumashta commented on HIVE-5217:
----------------------------------------

[~cwsteinbach] Sure, let me rebase on the trunk. You can look at the patch 
here: https://reviews.facebook.net/D12801, 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: https://issues.apache.org/jira/browse/HIVE-5217
>             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-5217.D12801.5.patch
>
>
> [HIVE-4617|https://issues.apache.org/jira/browse/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
(v6.1#6144)

Reply via email to