[
https://issues.apache.org/jira/browse/IMPALA-7561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong updated IMPALA-7561:
----------------------------------
Target Version: Product Backlog (was: Impala 3.1.0)
> Expired queries should end up in a consistent state (EXCEPTION, CANCELLED, or
> something else)
> ---------------------------------------------------------------------------------------------
>
> Key: IMPALA-7561
> URL: https://issues.apache.org/jira/browse/IMPALA-7561
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
> Reporter: Tim Armstrong
> Priority: Major
> Labels: query-lifecycle
>
> ClientRequestState treats "eos" as a terminal state and won't transition to
> EXCEPTION or CANCELLED out of it. See the below code snippet from
> ClientRequestState::Cancel():
> {code}
> bool already_done = eos_ || operation_state_ ==
> TOperationState::ERROR_STATE;
> if (!already_done && cause != NULL) {
> DCHECK(!cause->ok());
> discard_result(UpdateQueryStatus(*cause));
> query_events_->MarkEvent("Cancelled");
> DCHECK_EQ(operation_state_, TOperationState::ERROR_STATE);
> }
> {code}
> If the cancellation is initiated by the server (e.g. because of
> query_timeout_s or exec_time_limit_s) then we should arguably treat that as
> an exception and put the query into the EXCEPTION state (because it is not a
> user-initiated cancellation) if it is not already in an EXCEPTION or
> CANCELLED state. That way the client can see that the expiry happened and
> access the cause of expiry.
> One argument against using the EXCEPTION state is that admins or users might
> think that something went wrong and needs to be investigated, see IMPALA-471.
> A separate issue is that user-initiated cancellation should use the CANCELLED
> state: IMPALA-1262
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
