[jira] [Commented] (IMPALA-7561) Expired queries should end up in a consistent state (EXCEPTION, CANCELLED, or something else)

["Zoltán Borók-Nagy (Jira)" <ji...@apache.org>]

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

Zoltán Borók-Nagy commented on IMPALA-7561:
-------------------------------------------

Seems like Hive already added a TIMEDOUT_STATE to TOperationState:

[https://github.com/apache/hive/blob/665c44355db1b189f378df7561551e0ae06dd2cf/service-rpc/if/TCLIService.thrift#L475]

While in Impala we don't have this state yet:

[https://github.com/apache/impala/blob/285cea92910ee59a96a8c9c78c74272dedcbf1f9/common/thrift/hive-1-api/TCLIService.thrift#L424-L450]

Is there a reason why can't we just extend OperationState with TIMEDOUT_STATE and use it with expired queries (e.g. because of query_timeout_s, exec_time_limit_s, fetch_rows_timeout_ms, etc.)?

> 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
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org