Trigger States
A trigger in FlowForce Server can be in one of two states:
•Working normally: The trigger runs as scheduled without missing tasks.
•Overdue: The trigger misses its scheduled time due to a lack of execution slots (for more details, see below).
Overdue triggers
A trigger becomes overdue when it misses its scheduled time to run because no execution slots are available. When a trigger becomes overdue, it does not stack up missed executions. Instead, it waits for the next available execution slot.
How different triggers handle being overdue
A trigger remains overdue until it can perform its next primary task. The behavior varies depending on the type of trigger.
Timer triggers
For a timer trigger, the primary task is to run at a scheduled time. If that time passes and there are no available execution slots to run the task, the trigger becomes overdue. The trigger does not attempt to run multiple times because this would make the problem worse. Instead, the trigger waits until a slot becomes free.
However, even when a slot becomes available, the trigger might not get it immediately. Higher-priority tasks (like a service request or a higher-priority trigger) can take precedence. If multiple triggers of the same priority are waiting, the system uses internal rules to determine which one gets the slot.
File-system triggers
For a file-system trigger, the primary task is to scan a directory for changes. The behavior of file-system triggers is the same as for timers. However, a file-system trigger might have more than one item of work to process: When the directory is scanned, the trigger might find zero, one, or multiple items to process.
•If the trigger finds zero items, the execution slot is freed up immediately, and other triggers can compete for it.
•If the trigger finds one item, the slot is assigned to process that file.
•If the trigger finds multiple items, the trigger does not process them all in the same slot because this would be inefficient. Instead, the system creates multiple instances of the trigger, each waiting for its own execution slot to process one item. Once an item is processed, the corresponding instance is removed. This continues until only one instance remains, which can then perform the next directory scan.
HTTP triggers
HTTP triggers monitor a URL for changes by periodically checking its Last-Modified or Content-MD5 headers. Like other triggers, HTTP triggers can become overdue under certain conditions:
•If retrieving the resource takes longer than the configured check interval.
•If no execution slot is available when the trigger attempts to run.
Unlike file-system triggers, HTTP triggers monitor only a single URL (not an entire directory) and do not replicate themselves. However, the overdue behavior remains similar — the trigger waits until resources are free, and no additional checks are queued during this time.
Example scenario
For example, if you set a file-system trigger to scan a directory every 30 seconds, but the jobs it triggers take 10 minutes to complete, the trigger becomes overdue as soon as all execution slots are occupied. This happens because the trigger cannot rescan the directory for new files while all slots are busy. Even if it could detect new files, it would not be able to process them immediately due to the lack of available slots.
When slots free up, the trigger resumes scanning but remains overdue because it missed its scheduled scan time. This behavior is intentional because attempting to process everything immediately would reduce overall system efficiency and increase delays.
Overdue triggers are not necessarily a sign of problems; they indicate that the system missed a scheduled task due to resource constraints.
Possible solutions
If triggers become overdue too often, this might indicate that the server is overloaded. Consider the following suggestions:
•Reduce scan frequency to match job durations: If a job takes 10 minutes, scanning every 30 seconds is unnecessary. Therefore, you should increase the scan interval (e.g., 5 minutes) to align better with job completion times.
•Increase execution slots: If possible, allocate more execution slots to reduce wait times for triggers.
•Adjust scheduling: Space out triggers so that they do not all fire simultaneously. This will allow reducing competition for slots.
•Optimize job runtimes: Improve the efficiency of jobs to free up slots sooner.
•Upgrade server resources: Add more CPU, memory, or execution slots to handle higher workloads.