[
https://issues.apache.org/jira/browse/HIVE-5217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13817067#comment-13817067
]
Vaibhav Gumashta commented on HIVE-5217:
----------------------------------------
Thanks [~cwsteinbach]. I'll look the the feedback here and on rb.
Meanwhile on your last comment: getOperationStatus returns after
hive.server2.long.polling.timeout expires or the query completes - whichever
happens first. So if polling.timeout = 5000 and the query finishes in 1000, the
call to getOperationStatus will return in 1000. However, in the test case, the
test query we are running is very short - therefore to test the behavior of the
long polling timeout, we're explicitly setting the config to a smaller time
than default, which is 5000; otherwise if the query takes 3000, it will return
state FINISHED and we won't be able to test the timeout.
> 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-5217.D12801.6.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)
