The MID Server and the ECC Queue support Priority. Higher priority jobs can jump the queue, and execute in dedicated threads.
|Priority||Thread Group||No. Threads (default)||Parameter||work\monitors\ECCSender folder||Examples of probes|
|2 (default)||Standard||25||threads.max||output_2||JDBC, REST, SOAP, LDAP, Discovery...|
SystemCommand: restartService, grabLog, etc.
When the MID Server fetches the next batch of jobs from the ECC Queue, it will prioritise the lower numbered record. The same applies to the ECCSender thread when passing results back to the instance.
Generally everything should run at Standard priority, unless there is a very good reason why it needs to jump the queue.
As of Madrid, very few features deliberately set this to anything other than Standard.
- Discovery will use the priory of the Discovery Status record for all probes. This may vary depending on how the Discovery is launched.
Important note: Once all Interactive threads are in use, critical MID Server system commands can be blocked, including HeartbeatProbe which is used by the instance to know if the MID Server is up, so it will be set as Down. It's therefore a good idea to never use Interactive, and use Expedited for anything that must jump the Standard queue.
Since Geneva, when the Priority feature was added to the MID Server and ECC Queue.
LDAPConnectionTesterProbe for an LDAP Server connecting via a MID Server runs as Standard priority, even though it only waits a short time for a response. If a MID Server as jobs queued, such as during a Discovery, this will often timeout and cause the LDAP Server to be set as Down. That behavior may be changed by PRB1331240.
CommandPipeline for "Test Credentials" runs interactive runs as Interactive priority. This has been known to cause all threads to be in use, and cause a MID Server to go Down due to being unable to run any HeartbeatProbe or SystemCommands. That behavior may be changed by PRB1330701.
When a Discovery is Cancelled, the message to the MID Server to stop running any more jobs for it needs to jump the queue, and at present simply inherits the priority of the discovery_status. That can lead to some jobs continuing running for up to an hour after cancelling. That behavior may be changed by PRB1332197.
Final Note: "When everything is a priority, nothing is a priority", so don't be silly with this in custom implementations or you will defeat the purpose.