Allocation Monitor

The allocation monitor watches the queue and the number of allocated Engines, and requests Engines to be reserved based on four options.

The minimum and maximum amount of Engines that can be allowed to work concurrently on a Session are specified upon session creation, as MAX_ALLOCATED_ENGINES, MIN_ALLOCATED_ENGINES. This essentially specifies the number of active reservation tasks at any given time. There are no specific guarantees that Engines are available to take those tasks, however, a session can be given URGENT priority to provide for some level of guarantee of availability. The minimum specifies how many idle tasks are maintained if the operation queue is empty; the maximum caps the amount of tasks regardless of the queue.

The size of the operation queue is defined by ALLOCATION_OPERATION_QUEUE_THRESHOLD. Once the queue rises above the queue threshold the allocation monitor starts requesting additional Engines at the rate specified in the ALLOCATION_RATE option, and continues requesting at that rate until the queue size drops below the threshold, or until the maximum reservation count is reached. The queue monitor might also automatically extend a new reservation when an Engine completes its reservation after reaching one of its timeouts.

If SpeedLink tasks were allowed to remain active indefinitely, then this session could starve the grid of Engines, as this essentially becomes a session with long-running tasks. To prevent this, the ALLOCATION_TIME option specifies the maximum amount of time a task can be performing operations. If an operation is in progress when it times out, the operation is allowed to complete first. Also, the SpeedLink implementation adds “noise” to the timeout value so task completion events become randomly staggered. Additionally, the IDLE_LINGER time specifies how long a task can remain idle without performing operations before it automatically deallocates itself.