iPAM uses several queues to handle scheduling and data flow. The executive recognizes and controls three queues:
- Scheduler queue
- Input queue
- Output queue
The contents of the scheduler queue can be displayed using the administrative tool (which is accessible from the Toolpicker window). All handlers and daemons that are currently enabled will show up on that queue. The queue is sorted by order of "activation," with the next agent to be activated at the "top" of the queue. Only one item at a time will be taken from the top of this queue. As of the time of this writeup ( iPAM 2.4) this queue is examined every 2 seconds to see if there are any handlers or daemons that need activation. Most handlers and daemons perform simple tasks when they are activated. Most handlers simply activate their inputs when they are activated. However, a poorly written handler could conceivably hold up other activations if it performs any significant processing when it gets activated.When a synchronous input agent gets activated (usually because a handler it is connected to gets activated) it is placed on the input queue for execution. The input queue can simultaneously execute several input agents. The number is controlled by the exec parameter PIMThreadCount. Input agents are executed from this queue on a first-in, first-to-execute basis.
If there are too many input agents waiting for execution on the input queue the executive will complain that it has run out of queue slots. This will temporarily halt activations of handers off of the scheduler queue. This also generates an annoying sequence of messages until the situation clears up. This situation can usually be remedied by allocating a higher PIMThreadCount.
When all synchronous inputs to a handler complete then that handler is given time to aggregate or process its inputs. It is worth noting that the Java thread that provides time to the juggler is the thread that executed the last input to that handler (from the input queue). Thus, handlers that are processing inputs do not compete with handlers waiting for execution. On the other hand, handlers that take long to process their input will compete with inputs on the input queue.
When each handler has finished processing its input(s) it activates its outputs (if it has a product to output). Synchronous output agents are placed on the output queue for execution. Asynchronous output agents have their own input queues and do not compete with the asynchronous output agents. There are a fixed number of threads available for executing the output agents. This number is controlled by the exec parameter DIMThreadCount. As with the input queue it is possible to run out of queue slots in the output queue. When that happens the handler that is trying to activate output agents is blocked from completing. Since the handler is actually executing at that point from a thread belonging to the input queue, further input activations may also get blocked.
In addition to the executive queues there are other queues that are used and maintained by asynchronous agents. An example of such an agent is the handler named "queue". These queues can be assigned a priority based on the java priority numbering scheme. They do not compete with each other directly other than for processor time based on Java's built-in thread scheduling.Revised: 13 August 1999