[
https://issues.apache.org/jira/browse/IMPALA-7561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16979583#comment-16979583
]
Tim Armstrong commented on IMPALA-7561:
---------------------------------------
We really don't want to complicate the possible states any more by allowing
more combinations of query state and query status. We also don't want clients
to be parsing "Query Status", since it's mostly freeform text error messages.
I think the right fix is to make this behave the same as expiry for a query
that's not eos, i.e. transition it to EXCEPTION or CANCELED as if it's not at
eos. I'm concerned about the fallout though, because if that's done a lot more
queries will show up as EXCEPTION state, which can cause problems for people
running clusters because it looks like something went wrong with the query,
when it actually ran fine and returned all the results.
I do think that this shouldn't be a big deal for well-behaved clients. The only
reason it would make a difference (I think) is if the client ran the query,
fetched all the results, then defers closing the query until it's forcibly
cancelled by the server.
We strongly prefer if clients either close the query once they've fetched all
the results, or if they implement their own timeout based on the needs of the
users (some clients do want to page backward and forward in the result set,
which we do support). If they don't do this, and we implement this change, then
we'll have the problem of more queries *looking* like failures.
> 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: [email protected]
For additional commands, e-mail: [email protected]
