Navigation:  Features >

Work Queue

Previous pageReturn to chapter overviewNext page

The WorkQueue is the core processing engine of the ImageServer. Almost all processing done by the ImageServer is done through the WorkQueue. The WorkQueue is extensible, and uses the ClearCanvas framework plugin mechanism for adding new processors. Among the uses of the WorkQueue are the following:

Process incoming studies
Delete studies when triggered by the disk management service
Purge archived studies when triggered by the disk management service (See Service Scheduling)
Edit studies requested from the web GUI
Perform auto-routing
Delete studies requested from the web GUI
Move studies to devices requested by the web GUI
Cleanup studies that fail processing.
Handle reconcilliation of studies.
Migrate of studies between filesystem tiers.

The WorkQueue Shred has a single thread that queries the WorkQueue for work.  The thread then passes the job to a thread pool to process and complete the queue item.  WorkQueue entries will be scheduled at specific times and have an expiration time associated with them.  This allows a single queue entry over an extended period of time for processing a study or an auto-route request for a study. Note, however, that the expiration time is not used for all types of queue entries.

There are several configuration options that specify how WorkQueue entries are processed.  First, the WorkQueue reserves a configurable number of threads for High priority WorkQueue entries.  High priority WorkQueue entries are typically for study processing and editing, although other WorkQueue entries can be made a high priority through the Web GUI.  Second, some WorkQueue entry types are memory intensive, and the WorkQueue can be configured to limit the number of memory intensive WorkQueue entries that are being processed at any time in the thread pool.  Finally, the total number of threads within the thread pool can be configured.

The scheduling mechanisms for the WorkQueue reserves some of the thread pool for processing of new studies, and also allows limiting of the memory utilized by the service through limiting the number of threads in the pool  It also allows for multiple threads to be used for non-memory intensive WorkQueue entries.  This allows for a relatively flexible scheduling mechanism that adapts to the types of entries in the WorkQueue, but still reserves some processing of incoming studies.

A WorkQueue entry will also have multiple SOP Instance Uids associated with it, for processing specific SOP Instances. Each WorkQueue entry will have a Text field to insert XML data describing the actual job. This will be customized per WorkQueue type and is not used by all types.

If a WorkQueue shred goes down, when the shred is started up again, any In Progress status entries are reset to Pending. Ie, when a WorkQueue row is acquired for processing, the row contains an identifier for the service that is processing the queue entry, allowing for the row to be cleaned up when the service comes back online.

Work Queue Statuses

The ImageServer GUI has a mechanism for querying the contents of the Work Queue. Entries in the Work Queue can have status values of Pending, Idle, or In Progress. The following table summarizes the use of these statuses:

 

Status

Description

Pending

The entry is waiting to be processed

Idle

The entry has been processed and is waiting for a timeout before it is removed from the queue. No additional images are known to exist that need to be processed.

In Progress

The entry is currently being processed by the ImageServer.

Failed

The entry has failed processing.