Symptom: ARL Starts While Blocked

FlexNet Manager Suite 2022 R1 (On-Premises)

Even though other (time-consuming) tasks are running that should prevent the execution of the ARLImport task (as listed in Batch Processing Constraints), a queued request for ARLImport may suddenly trigger the execution of the task.

This is because the ARLImport task has (by default) a 60-minute 'starvation limit' that prevents it being held up (or 'starved' of processing time) for too long. Before the time limit is exceeded, tasks with lower exclusivity requirements (tenant scope, compared with the system/group scope for ARLImport) are allowed to run, even if requested later than the ARLImport task, where the latter is being delayed by other tasks. When the starvation limit is exceeded, the batch scheduler tightens constraints, and no longer allows tasks with lower exclusivity to 'sneak in' to the queue. Furthermore, as soon as the ARLImport is starved, any arriving request that would normally block the ARLImport is itself blocked first. These changes prioritize the queued ARLImport task for execution by moving it quickly to the front of the execution queue (for operational details, see How Batch Scheduling and Processing Works). This preemptive move prevents the task sitting in the Submitted state for an excessive (even indefinite) time, blocked by other constraining tasks.

By default, only the ARLImport task has a starvation limit. The number of minutes is stored in the StarvedAt column of the BatchProcessType database table. The use of this table means that it is theoretically possible to set a starvation time limit for all types of batch processor tasks. However, setting such 'preemptive strikes' on the batch scheduler is not recommended, since it is only useful for tasks with high exclusivity (like system) being starved by tasks with lower exclusivity (like tenant). Best practice is to allow the batch scheduler to fulfill its prioritization tasks without prejudice.