[
https://issues.apache.org/jira/browse/IMPALA-7561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong updated IMPALA-7561:
----------------------------------
Description:
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
was:
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
> 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]
