[
https://issues.apache.org/jira/browse/IMPALA-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16611221#comment-16611221
]
Tim Armstrong commented on IMPALA-1262:
---------------------------------------
[~dhecht] [~bikramjeet.vig] what state do we think the query should end up in
when it's expired, e.g. because of query_timeout_s or exec_time_limit_s? Is
that CANCELED, since there was no failure within the query, or is in an
EXCEPTION because it client didn't initiate the cancellation?
This came up because clients can't necessarily detect that the query expired if
they already fetched the final row. I.e. they might think that the query is
still valid and they can do things like restart fetching.
> user initiated query cancellation should return operation_state =
> CANCELED_STATE
> --------------------------------------------------------------------------------
>
> Key: IMPALA-1262
> URL: https://issues.apache.org/jira/browse/IMPALA-1262
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
> Affects Versions: Impala 1.4
> Reporter: Dan Hecht
> Assignee: Bikramjeet Vig
> Priority: Minor
> Labels: query-lifecycle
>
> I've been told that if the user cancels the query, our intention is to not
> set query_state to EXCEPTION. (Is that the desired behavior?) Adding a test
> case to test_cancellation.py as follows, shows that this is not the current
> behavior (at least not in all circumstances).
> {code}
> --- a/tests/query_test/test_cancellation.py
> +++ b/tests/query_test/test_cancellation.py
> @@ -102,6 +102,7 @@ class TestCancellation(ImpalaTestSuite):
> sleep(vector.get_value('cancel_delay'))
> assert self.client.get_state(handle) !=
> self.client.QUERY_STATES['EXCEPTION']
> cancel_result = self.client.cancel(handle)
> + assert self.client.get_state(handle) !=
> self.client.QUERY_STATES['EXCEPTION']
> assert cancel_result.status_code == 0,\
> 'Unexpected status code from cancel request: %s' % cancel_result
> thread.join()
> {code}
> One example of how this can happen is if the cancel happens while the wait
> thread is still in WaitInternal, then WaitInternal will return
> Status::CANCELLED, and UpdateQueryStatus indiscriminately sets query_state_
> to EXCEPTION if !ok(). But, I don't think that side of the execution can
> distinguish between user initiated cancel and error initiated cancel.
> Probably, QueryExecState::Cancel needs to remember which kind of cancellation
> it was so that the cancelled side can do the right thing.
> We don't have a general workaround.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
