Uploaded image for project: 'IMPALA'
  1. IMPALA
  2. IMPALA-7561

Expired queries should end up in a consistent state (EXCEPTION, CANCELLED, or something else)

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Backend
    • Labels:

      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():

          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);
          }
      

      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

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                tarmstrong Tim Armstrong
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated: