An error occurred fetching the project authors.
  1. 28 Oct, 2015 1 commit
  2. 19 May, 2015 2 commits
  3. 15 May, 2015 1 commit
  4. 13 May, 2015 2 commits
  5. 06 May, 2015 1 commit
    • 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
  6. 30 Mar, 2015 2 commits
  7. 27 Mar, 2015 1 commit
    • 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
  8. 14 Oct, 2014 1 commit
  9. 08 Oct, 2014 1 commit
  10. 04 Sep, 2014 1 commit
  11. 29 Aug, 2014 1 commit
  12. 22 Aug, 2014 2 commits
  13. 22 Jul, 2014 1 commit
  14. 23 Jun, 2014 1 commit
  15. 27 Nov, 2013 1 commit
  16. 06 Aug, 2013 1 commit
  17. 02 Aug, 2013 1 commit
  18. 28 Jun, 2013 1 commit
  19. 11 Jun, 2013 8 commits
  20. 10 Jun, 2013 2 commits
  21. 21 May, 2013 2 commits
  22. 20 May, 2013 1 commit
  23. 22 Apr, 2013 2 commits
    • Julien Muchembled's avatar
      CMFActivity: move message serialization code to Message class · ee2edadb
      Julien Muchembled authored
      Later, we might want to do more processing after loading, or before dumping,
      accessing private Message data.
      ee2edadb
    • Julien Muchembled's avatar
      CMFActivity: remove non-executable message state (-3) · e47f2923
      Julien Muchembled authored
      When an object is deleted, higher level code used to flush its messages (without
      invoking them). However, a concurrent and very long transaction may be about to
      activate such an object, without conflict. We already experienced false -3
      errors that could prevent other messages to be validated.
      
      Because there is no efficient and reliable way to flush absolutely all messages,
      messages on deleted objects are now ignored and deleted without any email
      notification. There's only a WARNING in logs. But for performance reasons,
      there's still a flush on object deletion.
      
      To simplify code, messages that went to -3 for other reasons, like a
      non-existing method, now go to -2. In fact, this was already the case for
      grouped messages.
      
      In case that a path is recycled, it may still be possible for a message to be
      executed on a wrong object (the new one), instead of being ignored (because the
      activated object was deleted). So in such scenario, developer should make sure
      not to delete an object that may be activated in a concurrent transaction.
      If the original object has an OID at the moment it is activated, an assertion
      will make sure the message is not executed on another object.
      e47f2923
  24. 28 Dec, 2012 3 commits