1. 12 Jan, 2016 3 commits
  2. 23 Dec, 2015 1 commit
  3. 28 Oct, 2015 1 commit
  4. 15 Jun, 2015 1 commit
  5. 19 May, 2015 2 commits
  6. 15 May, 2015 1 commit
  7. 13 May, 2015 3 commits
  8. 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
  9. 31 Mar, 2015 1 commit
  10. 30 Mar, 2015 2 commits
  11. 27 Mar, 2015 2 commits
    • Julien Muchembled's avatar
      CMFActivity: automatic migration of queues and removal of button to recreate tables · 3d644bde
      Julien Muchembled authored
      The action to recreate activity tables while preserving existing messages
      was unsafe for 2 reasons:
      - if any error happened, messages could be lost
      - it relied on Message.reactivate
      
      Which this patch, any instance created after commit d881edd1 (Aug 2010) will
      upgrade successfully. For older instances, make sure you have no activity left.
      
      For cases where 'ALTER TABLE' would not work, a better way to implement repair
      functionality would be:
      - one action to backup all messages in ZODB
      - and another to restore them
      And maybe a security so that during the backup-clear-restore sequence,
      activities can't be created nor processed.
      
      If any column is added in the future, it would still be possible to write code
      that fills them by inspecting messages.
      3d644bde
    • Julien Muchembled's avatar
      7c1ccdb0
  12. 25 Mar, 2015 1 commit
  13. 10 Mar, 2015 1 commit
  14. 12 Dec, 2014 1 commit
  15. 16 Oct, 2014 1 commit
  16. 14 Oct, 2014 1 commit
  17. 08 Oct, 2014 1 commit
  18. 04 Sep, 2014 1 commit
  19. 29 Aug, 2014 1 commit
  20. 22 Aug, 2014 2 commits
  21. 22 Jul, 2014 1 commit
  22. 23 Jun, 2014 1 commit
  23. 26 Feb, 2014 1 commit
  24. 30 Jan, 2014 1 commit
  25. 27 Nov, 2013 2 commits
  26. 11 Sep, 2013 1 commit
  27. 14 Aug, 2013 4 commits