Note with tips why activites may block on ERP5
Table of Contents
A set of values describing a method call: object on which the call takes place, method to call, parameters. It also describes conditions which must be true for the call to happen: absence of certain activities, point in time reached, relative message priorities...
Distributing Node deprecated naming
see: Validation Node
A Zope thread which executes validated Activities.
A pile-ish mechanism containing Activities. They come in various flavours:
RAM storage (at process scope).
SQL storage (cluster-friendly).
Execute all Activities. Not a queue strictly speaking, since it paralelises execution (if multiple activity processing)
Execute unique activities. If the same method is to be called on the same object (with some other criterions: same validation conditions, same validation metadata, same group_method_id) multiple times, only execute it once (drop similar pending Activities). It also affects Activity creation, since pre-creation merge also happens. This is especially useful for object indexation, because multiple indexations would just produce the same result again and again.
The Queue used by default is SQLDict.
Zope thread responsible for activity validation. Validation is the process of checking Activity data describing conditions to match before the Activity could be executed.
When one puts interest in CMFActivity, it's generally to understand why something gets stuck, or why activities are slowly executed.
So let's see how one can get a report on activity status.
Since there isn't any diagnostic tool for RAM-flavoured Queues, SQL-flavoured debugging is described here.
When a Zope transaction creates activities, they get inserted at transaction commit, if and only if the transaction was actually committed (ie, no error happened).
A newborn activity is in a non-validated state.
A non-validated activity will be periodically validated until it actually becomes valid (ie, it until conditions to make it executable are met). It will become a valid activity.
A valid activity will be picked up by an available processing node, which will process it.
Scheduling¶ status can be watched evolving from SQL tables.
SQLDict and SQLQueue use SQL tables to store Activities (message and message_queue resp.). Those tables have some columns used for activity scheduling.
Unique Activity identifier. This is number is displayed in Zope logs by CMFActivity when notifying a problem, so that the cause can be examined.
Not used. Available to manually set messages in a state where they do not impact activity scheduling.
Internal error: object on which the activity must be executed is not found, or the method to call is not found.
Activity error: object and method were found, but activity execution raised errors, and its priority reached the limit value.
Assigned to a processing node. The number identified the processing node which is now handling the activity. See the node configuration page to identify the Zope process.
Impacts validation: If true, Newborn activity validation will consider activities in this state. Otherwise, they will be completely ignored.
Not currently processed.
Any other value is illegal, since this column is checked for equality (with 1 or 0).
Highest priority (default value)
Lowest priority: if this Activity fails once, it will be put to "Activity error" state.
Any other value should work, but considered out-of-spec.