Uploaded image for project: 'JBoss Transaction Manager'
  1. JBoss Transaction Manager
  2. JBTM-3994

LRA doesn't seem to be able to reach end state FailedToCancel

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Done
    • Icon: Major Major
    • Narayana-LRA-1.0.2.Final
    • None
    • LRA
    • None

      Running on Quarkus 3.2.0 with LRA 1.0.1-Final, I have a setup with an initiating service that calls two participants. I simulate a failure in one of the participants, and thereafter I simulate a failure in the @Compensate method in the other service (returning FailedToCompensate, and returning this from the @Status method as well).

      The coordinator however eventually reports state Cancelled, where I think should report FailedToCancel.

      After some debugging, I observed that the problem is seemingly in LongRunningAction#endStateCheck:

       

      protected boolean endStateCheck() {
      
        // update the status first by checking for heuristics and failed participants
      
        if (status == LRAStatus.Cancelling && allFinished(heuristicList, failedList)) {
      
          return updateState((failedList == null || failedList.size() == 0) ? LRAStatus.Cancelled : LRAStatus.FailedToCancel);
      
        } else if (status == LRAStatus.Closing && allFinished(heuristicList, failedList)) {
      
          return updateState((failedList == null || failedList.size() == 0) ? LRAStatus.Closed : LRAStatus.FailedToClose);
      
      }
      
      return false;
      
      }
      

      I see my try participants in the heuristicList, but the code here expects the participant with the failedToCompensate state to be in the failedList.

      The failedList however is always empty, because in com.arjuna.ats.arjuna.coordinator.BasicAction.doCommit(boolean, AbstractRecord), `reportHeuristics` is always called with a "true" value. E.g in io.narayana.lra.coordinator.domain.model.LongRunningAction.runPostLRAActions():

      protected void runPostLRAActions() {
              // if there are no more heuristic outcomes then update the status of the LRA
              endStateCheck();
      
              if (isFinished() && heuristicList != null && heuristicList.size() != 0) {
                  if (preparedList == null) {
                      preparedList = new RecordList();
                  }
                  moveTo(heuristicList, preparedList, false);
                  checkParticipant(preparedList);
      
                  if (LRALogger.logger.isTraceEnabled()) {
                      trace_progress("runPostLRAActions");
                  }
                  super.phase2Commit(true);
              }
          }
      

      Subsequently, the code always adds all participants to the heuristicList as per this branch in the code:

      if ((reportHeuristics)
                                  && ((ok == TwoPhaseOutcome.HEURISTIC_ROLLBACK)
                                  || (ok == TwoPhaseOutcome.HEURISTIC_COMMIT)
                                  || (ok == TwoPhaseOutcome.HEURISTIC_MIXED) || (ok == TwoPhaseOutcome.HEURISTIC_HAZARD)))
                          {
                              updateHeuristic(ok, true);
                              heuristicList.insert(recordBeingHandled);
                              addDeferredThrowables(recordBeingHandled, deferredThrowables);
                          }
      

      Which, as mentioned above, results the `LRAStatus.FailedToCancel` is never being set.

      Am I doing something wrong? I checked a couple of paths, and there really seems to now to get anything in the failedList in this context.

      Maybe a solution is to iterate over all entries in the heuristicList in endStateCheck, to see if any has a failedToCompensate status, and then use that to set LRAStatus.FailedToCancel (and same for failedToComplete)?

      (I also noticed that the LRA TCK doesn't seem to have a test covering this)
       

       

              Unassigned Unassigned
              arjan.tijms@gmail.com Arjan Tijms (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: