Default computing trigger management


A computed attribute is triggered according to its inputs. An attribute cannot be computed on a given interval until all of its inputs are available on said interval.

In other words, an attribute based on two inputs A and B, cannot be triggered on interval ]10:00 ; 10:01] if it has not received A and B by this interval.

If A and B are not rhythmic inputs, a default rhythm is used, defined at the node level to trigger the computation. If A is an attribute that produces values only 2 hours a day (for example, from 07:00 to 09:00), it should not block all the attributes based on it.

Default rhythm what does it means?

Considering each attribute computed by the deployment, an attribute must be triggered at least at the default rhythm to ensure no attribute is left uncomputed.

Location: fields com.systar.krypton.scheduler.collector.defaultComputingRhythm.(scalar|unit) in  conf/


This property can be changed at runtime using the command Shell commands reference#changeDefaultComputingRhythm

(info) note that the value set using the command will be lost after a node restart. Once a correct value has been found,  conf/ should be updated accordingly.

Default lag what does it means?

By default, a lag is applied to ensure that each attribute is not computed too soon which would produce too many corrections. 

Location: fields com.systar.krypton.scheduler.collector.defaultComputingLag.(scalar|unit) in  conf/


This property can be changed at runtime using the command Shell commands reference#changeDefaultComputingLag

Note: The value set using the command will be lost after a node restart. Once a correct has been found conf/ should be updated accordingly.

How to determine default rhythm and lag on a node

Given these items:

On Cutoff and Process, the attribute inProcessCount and acquiredCurrentDayCount are computed with a rhythm of 1 minute, inProcessCountLast30minAvg is computed with a rhythm of 30 minutes,  acquiredFinalCount is an arrhythmic attribute computed at cutoff deletion.

Payments are injected every minute. It takes approximately 5 seconds to inject all payments.

In light of this information, we can determine the default rhythm to apply on the node.

The best way to do it is to use the smallest rhythm used by every computed attribute (1 minute).

  • If we use a rhythm greater than 1 minute, some attributes may not be computed at the right time. For example, using a rhythm of 30 minutes will force the InProcessCount and acquiredCurrentDayCount attributes to be computed every 30 minutes. Each time they are triggered, they will have to compute 30 minutes of data at once. If we display theses attributes on a dashboard with a rhythm of 1 minute, during 29 minutes, the value will be <Not set> and on the 30th minutes, a value will be displayed.
  • If we use a smaller rhythm, some attributes may be triggered too often. For example, using a rhythm of 1 second will trigger the computation of acquiredFinalCount every second which will load the node with a lot of computations especially if we display it in a dashboard with a rhythm of 1 minute.

Knowing that it takes 5 seconds to inject payments helps us determine the lag. If we have no idea of how long it takes, we can have a look at the number of the pending events in the Data integration area. 

  • If there are always some pending events, it is a hint to increase the lag to avoid corrections on the node.
  • If there are no pending events, but dashboards always display <Not set> values, it is a hint to decrease the lag.

Once determined, these settings can be changed and displayed using commands: Shell commands reference#Computing

Related Links