Uploaded image for project: 'Ambari'
  1. Ambari
  2. AMBARI-25606

Sometimes request aborting doesn't abort IN_PROGRESS task

Attach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 2.7.5
    • 2.7.6
    • ambari-server
    • None

    Description

      There is a raise condition in request aborting process.

      Imagine, we have a request with couple of stages/tasks and one task is in IN_PROGRESS state. Then let's try to abort the request.

      Crucial steps of request aborting are:

      1. Get all not completed tasks for the request.
      2. Get QUEUED and IN_PROGRESS tasks from #1 and send cancel commands to the agents (we've sent cancel command for our task).
      3. Get tasks in HOLDING_STATES (HOLDING_FAILED etc.) from #1 and try to abort them.
      4. Get all tasks form stages which are not in COMPLETED state for the request.
      5. Get tasks from #4 which are in PENDING, QUEUED, IN_PROGRESS states and abort them.

      But if the server receive response from the agent for cancel command (sent in #2), then task will be transitioned from IN_PROGRESS to HOLDING_FAILED state. That's ok if it happen before step #2 (it will be aborted because has HOLDING_FAILED state) or after step #5 (it had IN_PROGRESS state and was aborted; update from the agent won't change state to HOLDING_FAILED, because we handle this case).

      But if we receive response from the agent between steps #3 and #5, then task will not be aborted and we will get a task with HOLDING_FAILED state after abort operation completion.

      Attachments

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            hapylestat Dmytro Grinenko
            dvitiiuk Dmytro Vitiuk
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 40m
                40m

                Slack

                  Issue deployment