The following sections describe the queues that are established when your Windchill solution is installed. When optional products are installed, additional queues can be established. These queues are described as part of the product description. For example, the queues used for file vaulting are described in Out-of-the-box Background Queues for External Vaulting and the queues used for content replication are described in Out-of-the-box Background Queues for Replication.

The CollectorBasedPackageQueue enables collector-based package collections to refresh as a background process. This frees up resources available for foreground processes by moving collections to the background. By default, this is disabled. The following properties are useful for this queue:

The commonScheduleQueue is used for a variety of low-volume queue entries. These low-volume entries require limited resources and are often run only once or infrequently. Combining these queue entries into the commonScheduleQueue frees system resources to focus on high-volume queues. The following list describes each commonScheduleQueue entry type:

LicenseScheduleQueue is an immutable queue and is used for license related queue entries. Since the queue is immutable, you cannot perform actions such as stop, disable, edit, reset, or delete on the queue or its entries. These actions are hidden in the Queue Management user interface for the LicenseScheduleQueue. License related queues can be created and modified by PTC only.

The following list describes each type of entry in LicenseScheduleQueue:

The ContentControlQueue is used when the content control functionality for packages has been enabled. The content control feature allows a user to specify which content files should be included in the package delivery from the Files Table by selecting Select Files from the Actions menu on the Package Content table. The content control functionality needs to be explicitly enabled using a type-based properties file as described in Package Type-Based Properties.

When the content control functionality for packages has been enabled and a package is locked (or subsequently unlocked), a new entry is added to the queue. Similarly, any change in package member content control information that is made through Package Content user interface adds new entries to the queue. When a queue entry executes, content control data for package members is persisted.

The CtScheduleQueue is used when you have turned on the automatic scheduling of team updates.

For more information about automatic scheduling of team updates, see Synchronizing Teams with User-Defined Groups.

The dataMonitorProcessingQueue, along with the dataMonitorScheduleQueue, are used with the Windchill reporting data monitor functionality. When a scheduled instance of a data monitor is executed, an entry is added to the dataMonitorProcessingQueue. When a data monitor is deleted, any dataMonitorProcessingQueue entries will be deleted once they have finished executing. The dataMonitorProcessingQueue status is displayed in the Status column of the Executed Reports table on the data monitor information page.

The dataMonitorScheduleQueue, along with the dataMonitorProcessingQueue, are used with the Windchill reporting data monitor functionality. When a data monitor is created, an entry is added to the dataMonitorScheduleQueue for each scheduled instance of the data monitor execution. When a scheduled instance is executed, and entry is added to the dataMonitorProcessingQueue. When a data monitor is deleted, all dataMonitorScheduleQueue entries for that data monitor are deleted. The dataMonitorScheduleQueue status is displayed in the Status column of the Data Monitors table.

The DataSharingQueue is used when there is sharing of data between contexts. In some cases, the update of the sharing status involves heavy processing. For example, if a folder is shared, all foldered objects are also shared, recursively. This queue is used to process this type of updating in the background. The queue is used so that user response time is not affected by shared update processing.

The DeleteCompletedWorkItemsQueue deletes the completed work items for a specific participant in a specific context. Prior to deleting the work items, DeleteCompletedWorkItemsQueue reads the preferences. The preference value can be a number or ALL or NO. If the value is NO, completed work items are not deleted. If ALL, then all completed work items are deleted. If the value is a number, that is the number of the latest work items completed not deleted. The rest of the work items are deleted. The deletion of completed work items is spawned only when the number of excess completed work items is twice the specified preference. For example, if the preference is 10 then the deletion of work items is spawned only when the number of excess work items is 20. Note that a work item is deleted only if the parent process for it is CLOSED. The completed project work items are not deleted.

The default value of the preference prior to Windchill 9.1 M070 or Windchill 10.0 was 100. The current default is NO.

Failed entries in this queue cause the operation to fail while deleting the completed work items (as determined by the preference).

The DigestNotificationQueue is used by the notification service to queue requests to send mail. Requests are queued to send digest notification emails for notification subscriptions that are to be delivered according to a schedule rather than immediately. The subscription user interface allows users to select the delivery method when subscribing to an object. A preference can be set at the Site level or the Organization level to set the delivery time for digest notifications. The Organization level preference applies to users in that organization, the Site level preference applies to users not covered by an Organization level preference. Requests are queued on the DigestNotificationQueue for each unique preference value to schedule the delivery of digest notification emails, and these requests deliver the digest notification email to any user covered by the preference represented by the request.

The DTODeliverablesQueue handles deliverables requests, that is, a user requests generation of the deliverables from a configurable (formerly generic) part. Requests are put into the queue, processed, and results are sent back to the user when complete. The only out-of-the-box supported deliverables maker is the BOMMaker, which generates variant part structures. This generally runs quickly. There are other deliverables makers and it is possible for customers to write their own deliverables makers, which may take a long time (minutes or hours). The DTODeliverablesQueue is most useful in these cases.

The DTOOffPeakQueue handles running tasks that should run during off-peak hours (for example, at night). These tasks are long running and not a priority. For example, one task might search for potential variants of configurable parts and attach them as variants.

The EMailQueue is used by the mail service to queue requests to send mail. When a request is made to the mail service to send email, that request is queued on the EMailQueue. When the request is processed from the queue, the email is sent. The mail service also uses the queue to retry sending emails that failed to be sent. When a request to send an email fails, the mail service requires the request to be processed again after delaying for a period of time. By default, a request to send email is valid for 24 hours; if the mail service hasn't successfully processed the request by then, the mail service gives up trying to send the email for that request.

The forumEventPropogationQueue is used by Discussion Forums to delete the following objects:

Failed queue entries can mean one of the following:

You should check this queue each day to ensure that the queue is working properly. If there is heavy use of Discussion Forums, you may want to check the queue more often. For each failed queue entry, reset the queue entry state to ready.

Indexing Queue and Bulk Indexing Queue are optional queues that are set up when you install Windchill Index Search. These queues are used in the indexing process. You should periodically check the Indexing Queue and Bulk Indexing Queue for failed entries.

If an indexing queue entry has a Severe status, ensure that the indexing and the search engine are configured correctly and that theWindchill Index Search software is running. Then reset the queue entry to Ready. Resetting the queue entry restarts the indexing process.

The IXRepositoryQueue is used by the package Standard Received Delivery Service to create object information for import. This information will be used during a package import for the creation of batches.

When the user uploads a ZIP file containing package data, a queue entry comprising of the ReceivedDeliveryChunkInfo (ZIP information) is added to this queue. When the queue entry executes, metadata information is created for objects in the ZIP.

The NotificationQueue is used by the notification service to queue requests to generate and send notifications (policy and subscription based notifications).

There are two types of subscriptions/notifications supported by the notification service:

The NotificationQueue is used for both the e-mail subscriptions and the Object Listener subscriptions; therefore, NotificationQueue must be started for WfSynchRobots to be notified so they can do the desired processing when their subscriptions are satisfied. Stopping the NotificationQueue prevents email notifications from being sent and it prevents Object Listener subscribers from functioning.

The NotificationScheduleQueue is used by the notification service. Requests are queued to expire subscriptions. The subscription UI allows users to set an expiration date for subscriptions, and the queued request is what removes the subscriptions at expiration.

The PartsLinkQueue is an optional queue that is set up when Windchill PartsLink is installed. The queue is used by the Windchill PartsLink Service to publish the parts which have been classified to the PartsLink Server.

You should periodically check the PartsLinkQueue for failed entries. If an entry has a failed status, the only action needed is to reset the queue entry to Ready.

The ProjectScheduleQueue is used by Classic Project Management for sending events corresponding to missed, approaching, and past deadlines.

There is no need to periodically check this queue; a failure in this queue is extremely unlikely. If there are complaints that project management deadline messages are not being sent, this queue should be checked. However, notification failures are more likely to be caused by problems with the email server.

The PublisherQueues are created for use by Visualization Services to manage the publishing and printing of visualization data, as well as related engineering calculations, such as interference detection. Additionally, when content synchronization is needed during the package zip process, Windchill Packages adds entries to PublisherQueues as described later in this topic.

Typically for Visualization Services, CAD data is published following a checkin. As a result, many customer sites use these queues heavily to execute jobs that run for a long time (possibly hours). Each PublisherQueue follows a naming convention of either PublishQueue<queueset>L/M/H or PublishQueue<queueset>N, where L/M/H stand for low/medium/high priorities and N is a sequential integer starting at 1. Queues with the same queueset are termed as a queue set. A default queue set, with an empty string as the name, always exists; all addition queue sets must be declared by the publish.publishqueue.setnames property in wvs.properties. The following queue sets and queues are created out-of-the-box:

All submitted WVS jobs are added to the priority queues (names ending in L, M, or H), depending on the job type, the way the job was submitted, and the type of data. This process is controlled by property settings in wvs.properties. For details, see the following properties in wvs.properties.xconf:

The executing job in an L, M, or H priority queue is looking for an available number queue (names ending with a sequential number N) in the same queue set. If it finds one, it submits the WVS job to that queue, which immediately executes it. By default, only one number queue is created for each queue set. Additional publish queues (for example, PublisherQueue2, PublisherQueue3, PublisherQueueCLASH2, and so on) can be created with the Windchill Queue Management utility for scalability.

The objects stored in the queue entries are com.ptc.wvs.server.publish.PublishJob, com.ptc.wvs.server.publish.ClashJob, or com.ptc.wvs.server.publish.PrintJob objects. You can view details of these WVS jobs from the WVS Job Monitor. If a job has failed, use the log information of the queue entry (shown in the WVS Job Monitor) to investigate why it failed. After fixing the problem, resubmit the job.

When exporting and zipping Windchill Packages, entries can be added to one of the default PublisherQueues, such as PublisherQueue1. The purpose of these entries is to update any CAD content being exported to include any Windchill metadata changes related to that content.

To use queues for CAD content synchronization when exporting and zipping packages, specific package preferences must be set. For preference details, see Setting Package Preferences.

When package preferences are set to enable the use of queues, the queue processing used is the same processing that is used by the Visualization Services when it generates representations. The objects stored in package queue entries are com.ptc.wvs.server.publish.PublishJob objects. Therefore, the Windchill Package queue entries have the same attributes as entries from Visualization Services. Similarly, you can view details of these jobs from the WVS Job Monitor. If a job has failed, use the log information of the queue entry (shown in the WVS Job Monitor) to investigate why it failed. After fixing the problem, repeat the package export.

RDImportExecutorQueue handles the importing of received delivery packages. When the Import action is launched for a received delivery, an entry with the received delivery identity information is added to this queue. When the queue entry is executed, the import of the received delivery is triggered. For information about importing, see Importing Received Delivery Files.

The received delivery import can be a lengthy process based on number of objects or number of files to process.

The WfPropagationQueue is used by workflow (and its associated tasks) to propagate all state changes to Workflow objects. This includes any routing expressions and transition expressions associated with those state changes.

The workflow queues are likely to be used heavily when many concurrent Windchill users are completing workflow tasks. Also, they are likely to be used heavily in scenarios where Windchill business objects are created that use life cycles which in turn use workflows.

If the performance of workflow queues is an issue, you can set up queue pooling that includes WfUserWorkQueue and WfPropagationQueue queues. The WfPropagationQueue queues in the pool are named WfSharedPropagationQueue<n>, where <n> starts at 1 and increments by 1 for each additional queue. For the details on setting up queue pooling, see Queue Pooling.

Failed entries in workflow queues mean that something failed to process correctly. In most cases, a failed workflow queue entry corresponds to a stack trace in the method server log. Analyze the queue entry failure by checking the method server log to determine the cause of the failure. Sometimes, the message listed in the Queue Management utility can be enough to determine the cause of the failure.

You should examine workflow queues when the workflow activities associated with the queues do not appear to be executing properly. Additionally, it is good practice to periodically check the queues to clean out old entries.

The WfScheduleQueue is used by workflow (and its associated tasks) to queue all timed events. Deadline checks for any workflow object with a deadline set and expression-based Synchronization Robots are executed within this queue.

The workflow queues are likely to be used heavily when many concurrent Windchill users are completing workflow tasks. Also, they are likely to be used heavily in scenarios where Windchill business objects are created that use life cycles which, in turn, use workflows.

Failed entries in workflow queues mean that something failed to process correctly. In most cases, a failed workflow queue entry corresponds to a stack trace in the method server log. Analyze the queue entry failure by checking the method server log to determine the cause of the failure. Sometimes, the message listed in the Queue Management utility can be enough to determine the cause of the failure.

You should examine workflow queues when the workflow activities associated with the queues do not appear to be executing properly. Additionally, it is good practice to periodically check the queues to clean out old entries.

The WfUserWorkQueue is used by workflow (and its associated tasks) to instantiate workflow robots and execute workflow robot actions.

The workflow queues are likely to be used heavily when many concurrent Windchill users are completing workflow tasks. Also, they are likely to be used heavily in scenarios where Windchill business objects are created that use life cycles which in turn use workflows.

If the performance of workflow queues is an issue, you can set up queue pooling that includes WfUserWorkQueue and WfPropagationQueue queues. The WfUserWorkQueue queues in the pool are named WfSharedUserQueue<n>, where <n> starts at 1 and increments by 1 for each additional queue. For the details on setting up queue pooling, see Queue Pooling.

Failed entries in workflow queues mean that something failed to process correctly. In most cases, a failed workflow queue entry corresponds to a stack trace in the method server log. Analyze the queue entry failure by checking the method server log to determine the cause of the failure. Sometimes, the message listed in the Queue Management utility can be enough to determine the cause of the failure.

You should examine workflow queues when the workflow activities associated with the queues do not appear to be executing properly. Additionally, it is a good practice to periodically check the queues to clean out old entries.

The WPSyncQueue handles package exports. Each zip action on a package results in a single entry on the WPSyncQueue for the length of the zip process. Package zipping can be a long-running process when there are a large number of objects or objects with large content.

Additionally, when content synchronization is needed during the zip process, queue entries are created on PublisherQueues to synchronize that content. Content synchronization occurs when supported CAD content is in the package and content synchronization is enabled.