[ https://issues.apache.org/jira/browse/IMPALA-7561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16637107#comment-16637107 ]
Tim Armstrong commented on IMPALA-7561: --------------------------------------- See [~jeszyb]'s comment on IMPALA-4714 for a reason why we shouldn't use EXCEPTION as the state here - it makes users/admins think something went wrong. > Expired queries should not stay in FINISHED state when at eos > ------------------------------------------------------------- > > 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} > I think that if the cancellation is initiated by the server (e.g. because of > query_timeout_s or exec_time_limit_s) then we should 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. > 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: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org