1. 20 May, 2015 2 commits
  2. 19 May, 2015 5 commits
  3. 18 May, 2015 3 commits
  4. 15 May, 2015 3 commits
  5. 14 May, 2015 2 commits
  6. 13 May, 2015 6 commits
  7. 12 May, 2015 2 commits
  8. 11 May, 2015 7 commits
  9. 08 May, 2015 5 commits
  10. 06 May, 2015 2 commits
    • Julien Muchembled's avatar
      CMFActivity: slightly delay non-executed grouped messages · c85a840f
      Julien Muchembled authored
      When grouped messages fail, ActivityTool must distinguish 3 groups,
      in order to reexecute them separately, as follows:
      - first, those that succeeded
      - then, those that were skipped
      - at last, failed ones
      
      Grouping methods are updated to handle partial failures, and stop doing
      anything when something goes wrong.
      
      Without this, we would have the following pathological cases.
      
      1. Let's suppose first that skipped messages are marked as succeeded.
      
      The problem is that each skipped message that will fail causes the reexecution
      of those that didn't fail.
      
      Exemple: A:ok B:ok C:err D:err E:err F:err
        1: A:ok, B:ok, C:err, D:skipped, E:skipped, F:skipped
        2: A:ok, B:ok, D:err, E:skipped, F:skipped
        3: A:ok, B:ok, E:err, F:skipped
        4: A:ok, B:ok, F:err
        5: A:ok, B:ok -> commit
      
      And worst, the first failed (C) may be processable again before 5, entering
      a failing loop if it is executed again in the same group as A & B.
      
      2. Another implementation is to mark all skipped as failed.
      
      Example:
        1: A:ok, B:ok, C:err, D:skipped, E:skipped, F:skipped
        2: A:ok, B:ok -> commit
        3: C:err, D:skipped, E:skipped, F:skipped
       >3: same as 3
      
      => D, E or F are never tried.
      c85a840f
    • Julien Muchembled's avatar
      CMFActivity: in case of ConflictError, retry earlier than for other failures · 30fbdd3d
      Julien Muchembled authored
      This tweaks retry delays as follows (seconds):
      
              ConflictError  other failures (K = 1 + retry², with retry >= 0)
      before     30             15 * K
      after      15             30 * K
      
      Today, bigger delays in case of errors should not be an issue because the
      quality of ERP5 has improved a lot and normal code should not rely anymore on
      this.
      
      We also don't want to lower ConflictError delay too much, because this
      increase the probability of conflicts.
      
      This will be required to improve invokeGroup, in case that a message fails.
      We'd like that:
      - successful messages are retried immediately
      - skipped messages are retried next, and separately
      - at last, failed messages are retried, also separately
      30fbdd3d
  11. 05 May, 2015 2 commits
  12. 03 May, 2015 1 commit