Queue dbdicts

Queue dbdicts contain records that are created by any session, and processed by a dedicated background process, which finally deletes it. Queues implement asynchronous task execution, and are also used to schedule task execution.

Queue dbdicts require monitoring in order to prevent system performance degradation, and require background processes to process the queue records.

The out-of- box queue dbdicts are described in the following table.

Dbdict name	Description
schedule	Scheduled tasks of many different kinds, such as output of on-screen messages, or sla processing.
eventin	Queue for incoming events
eventout	Queue for outgoing events
irqueue	Queue for IR index updates (asynchronous)
SMISTaskQueue	Service Manager Integration Suite (SMIS) provides a management framework for schedule-based and UI-based integrations using the web services or RESTful API. With SMISTaskQueue, schedule-based integrations are realized.
reportscheduleTasks	Files for scheduled tasks of the Reporting module
spool spoolheader mail	These queue dbdicts were used for server-side printing and the internal mail system, and are not used in most systems anymore.

Because some queue dbdicts have a high frequency of record creation and deletion, efficient indexing of the tables on the RDBMS is important. Also, preparing for temporary steep increases or decreases in the number of records is important.

Schedule dbdict

The schedule dbdict contains records that are tasks for most background processes (the so-called “schedulers”). All schedulers execute the same main RAD application named scheduler.process, while the schedule record contains the implementation.

Schedule records are used to achieve the following goals:

• Schedule a task into the future (for example, SLA alerting) using the expiration time field;
• Move time consuming processing from foreground sessions to background processes to increase response times, or
• Implement periodically interval-based rescheduled tasks

Other queue managers such as the event scheduler and the SMIS background tasks are implemented as schedulers using periodically rescheduled schedule records.

Important fields in a schedule record are described in the following table.

Field	Description
Expiration time	This field contains the time after which the schedule record is to be processed.
Class	This field contains the name of the background scheduler to process this schedule record when the task is scheduled. While a background process is processing it, however, it is empty.
scheduled class	This field contains the name of the background scheduler while it processes the schedule record. For a rescheduled schedule record, this field is also filled even if the record is only scheduled.
Status	This is a free-text field used to provide status information about the schedule record by the scheduler.process RAD application.

When the background scheduler wakes up, it looks for expired schedule records whose Class field contains its own name. It processes all these records, deletes each of them after they are processed successfully, and goes to sleep again. The sleep time is configured in its startup command (in the info dbdict using the info.startup format, or the sm.cfg file). It is recommended to not set the sleep time to be less than 15 seconds. The default value for most schedulers is 60 seconds.

Only when the scheduler is started for the first time, it checks for all schedule records that have a status of “application running” and a scheduled class that contains its own name. This is to ensure the task that was processed by a scheduler is completed before it is terminated prematurely. Because this is also the case for hanging schedule records, the system administrator needs to edit the hanging schedule record before restarting the background process.

Typical scenarios of failures in schedule record processing are described in the following table.

Status	Description
scheduled or empty status field	This is a normal state as long as the expiration time has not passed. If expiration time has passed, corrective actions are required.
application failed due to error - check msglog for possible messages	An error occurred while processing a schedule record and the schedule record gets into an “Application error” status. The background scheduler continues to pick up the next schedule record and continues to process its tasks.
locked	A schedule record could not be processed because resources required were locked. The schedule record gets into a “locked” status and is rescheduled for a few minutes later. The background schedule continues to pick up the next schedule record and processes this record at the rescheduled time.
application running	This is a temporary state while the schedule record is being processed. If this temporary state persists, it is likely that the scheduler processing this record got into an endless loop, which is also referred to as “hanging”.

The background processes can be monitored by the status monitor. The important column in the following table is Idle Time.

Idle Time	Interpretation and administrative action
> Sleep time	The scheduler is not running properly. Normally, killing and restarting the background process should resolve this issue.
00:00:00	If the idle time is exactly 00:00:00, press the Refresh button several times and watch if the idle time is increasing. If not, the schedule record is very busy or hanging. To identify this, check schedule records with a status of "application running” for a Scheduled Class field value that contains the process name. If there is no hanging schedule record, while the idle time stays 00:00:00, there is a load issue. Inspect all schedule records for this background process (the Class field) to understand the root cause of the load and then take adequate actions.

Irqueue dbdict

The IR index is a full-text searching implementation for Service Manager dbdicts. Updating the IR index is a time-consuming process, and the response time when updating records in a dbdict with an IR key would increase. For that reason, Service Manager instead writes a record to the irqueue dbdict as a task for the IRQUEUE background process which then executes the task.

Starting with Service Manager 9.33, the IR regen is executed asynchronously, which means an irqueue record for each record of the regened dbdict is created. This implementation is slower than the previous synchronous approach, but no longer requires a downtime.

Eventin dbdict

The eventin dbdict contains incoming events. Eventin records may be processed synchronously or asynchronously depending on the state of the “Process input events synchronously?” flag in the eventregister record.

Synchronous processing is implemented by the “eventin.after.add” trigger.

Asynchronous events use the evtime field. Eventin records are selected by the event background process based on a query specified in the schedule record of the event class, which is always rescheduled.

Incoming events can be configured to automatically create an outgoing event as the response. Successfully processed events are automatically deleted (if not configured otherwise, for example, for debugging purposes), while events that were not processed successfully are not deleted automatically to allow error analysis.

Eventout dbdict

The eventout dbdict contains outgoing events, which will be picked up by a background processor and then sent to an external application such as an email service.

SMISTaskQueue dbdict

When using Service Manager Integration Suite (SMIS), the queue of pending tasks can be inspected using Integration Manager. Repeated inspections help identify if the task queue is stuck and if a corrective action is required.

ReportscheduleTask and reportscheduleHistory dbdicts

The Reporting module queues tasks in the reportscheduleTask dbdict, and moves them into reportscheduleHistory after processing. The Reporting module also takes care of the cleanup of old records.

The Reporting module has its own cleanup mechanism implemented.