[ https://issues.apache.org/jira/browse/IMPALA-7561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tim Armstrong updated IMPALA-7561: ---------------------------------- Summary: Expired queries should end up in a consistent state (EXCEPTION, CANCELLED, or something else) (was: Expired queries should not stay in FINISHED state when at eos) > 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} > 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