Daemons are tasks that run continuously in the background of the Infinity Process Platform Engine. They play an important role in setting automatic triggers and events. The system provides two daemons by default, the System daemon and the Event daemon. Apart from them, daemons are created for every pull trigger defined in the model, like for example mail trigger or timer trigger.
The daemon execution is triggered at fixed intervals by a timer service. This timer service will start a short-living thread for each daemon type that is supposed to be started. Stopping the daemon stops the timer, so that no more executions are scheduled. Starting the daemons means that a corresponding timer is created that schedules execution jobs. A locking system guarantees that there are no overlapping job executions of the same daemon, i.e. a second execution will not start if the previous one has not yet finished. Server stopping will automatically stop the timers.
The following options are available to start or stop daemons necessary to run Infinity Process Platform:
The periodicity of the timer service can be individually configured in the Infinity Process Platform properties file. For details refer to section Daemon Properties. The total loop duration is the maximum (not the sum) of the duration of the loop tasks and the configured periodicity.
In some cases you like to exclude daemons to be executed in parallel. For this
purpose you can set a list of all daemons that should not be executed in parallel to
property Stardust.Engine.Daemon.ExclusiveExecutionTypes in your
carnot.properties file. For example:
Stardust.Engine.Daemon.ExclusiveExecutionTypes = criticality.daemon,benchmark.daemon
This setting forces the engine to avoid parallel execution of the criticality daemon and the benchmark daemon. If the benchmark daemon is currently executing a job, it cannot execute a second instance of the daemon job (standard lock mechanism) as well as any job of the criticality or benchmark daemon.
A running daemon is automatically restarted after a server restart.
Daemons communicate with the Infinity Process Platform Administration Perspective or with the console via timestamps in the audit trail database. If you intend to start and stop daemons from multiple machines, the machine system time must be the same on all machines.
The acknowledge mechanism determines to wait at least one timer periodicity before a guaranteed "is running" is received.
Operations on event daemons are partition-aware. Each operation applied within a partition-aware service is supposed to only consider the partition for which the service has been instantiated for.
The following predefined daemons are currently provided:
On the technical side, the mail daemon periodically polls the mail servers of all mail triggers defined for process definitions of a workflow model. If a new mail matching the specification of the mail trigger is found, a process instance is created.
The process instance is created asynchronously to the daemon execution. All the data contained in the trigger mail, and possibly necessary for executing the activities in the process, are passed as workflow data to the process instance.
The timer daemon periodically checks if timer-based triggers defined for the running process instances have to be fired. If a timer-based trigger matching the current timestamp is found, a new process instance is created asynchronously to the daemon execution.
The event daemon checks whether timer events were fired and need processing. The daemon periodically checks all event handlers bound and executes the event actions corresponding to matching handlers.
The system daemon periodically checks if daemon actions are defined and executes those actions. Please note that currently only one action is available, which is responsible for password expiration notification. In case this action is started and password rules are set, it is checking password expiration and sending a notification mail according to the password rules settings. Per default it runs once per day.
The prioritization daemon:
The reporting daemons runs periodically to check the next recurrence date for a Report Definition. Once the next recurrence date arrives, it executes the report and distributes it via the specified delivery method.
The benchmark daemon performs benchmark calculations at scheduled intervals.
Please refer to section Benchmark Daemon of chapter Benchmarks for details on Benchmark calculations.
The business calendar daemon cleans up calendars that reference an invalid business object instance. Every time the daemon processes such calendar entry it resolves the associated business object. Only one event entry cannot be resolved,
A log entry is recorded in the audit trail to support analysis of such events.
If an execution fails with an exception, the next execution is triggered by the system timer event not being affected by the former exception. An exception is errors based on database connection problems.
When encountering an Exception, except in cases where it would not even be able to write to the database, because for example of connection problems, log entries are written by daemons. These log entries are stored in the audit trail, in the table daemon_log. Please refer to the chapter The Repository Model of the Operation Guide for details on this table.
Daemons are configured via a set of parameters, which, depending on the operating mode, can be provided either in the deployment descriptor of the DaemonListener or in the carnot.properties.
The most important property for daemons is the periodicity:
where <daemon name> includes the following:
The periodicity controls how often the daemon should perform its task. By setting the property you can specify a time interval expressed in seconds between the executions to achieve more accuracy. The default value for all daemon types is 5 seconds except for the reporting and business calendar daemon.The reporting and business calendar daemon has a default periodicity of 60 seconds.
If the periodicity of daemons is increased by using these properties then the following behavior is expected:
The default value for daemon timeout period is set to 5 seconds. You can adapt this value in the carnot.properties file by setting the Carnot.Engine.Tuning.FindDaemonLogQueryTimeout parameter. The value "0" means that no timeout is performed.
All the events that need to be handled by the event daemon or timer trigger are stored in the event_binding table. When the thread for the event daemon starts, it reads all the entries in this table, which have a target timestamp that expired. For each event action, a separate transaction is started. Thus, if the transaction rolls back, the daemon thread itself will remain running and process the next event. The rolled back event will be handled during the next execution of this daemon type. The event itself is handled in a separate thread, whereby the following two types of exceptions are caught:
Unrecoverable exceptions will remove the event binding from the database table, mark a log entry, and subsequently commit (so that the daemon thread can continue with the next event). The runtime exceptions will first start a retry mechanism. After five times it gives up and mark this event as disabled. It does so by adding 1024 to the type field, which else holds 1 for process instances and 2 for activity instances (1025 means disabled process instance).
The process engine as well as the Portal can be deployed on multiple nodes within a cluster. There is no need to synchronize state between the nodes. The single point of synchronization is the audit trail.
In a clustered IPP environment the behavior of daemons depends on the clustering capabilities of the underlying application server. With standard configurations, no failover is provided and it is not guaranteed that there is only one instance running. It is guaranteed however that a specific event or action is performed by exactly one instance, i.e. different instances will execute different sets of actions, possibly in parallel.
Note that, depending on the platform used, there might be cluster able timer bean implementations providing failover and uniqueness on the level of the application server. Please check with your specific user platform.
If all configured as clusters in EBJ mode, the EJB timer guarantees that only one timer event will be executed for all cluster nodes.
A heartbeat is executed on every Infinity Process Platform instance. Every instance will check the daemon_log table, if a daemon execution is required, based on the last execution time in the database and the next execution time calculated by the periodicity. If a new run is required, a lock on the audit trail is acquired which will be available to only one engine. All other engines will not acquire the lock and only see the updated last execution time. Thus they wait another time. If no new execution is required as last modification time + periodicity > current time, the heartbeat sleeps and tries again during the next run.
For a Process Model Deployment in a clustered Environment please note the following: