Out-of-the-box Background Queues
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.
CollectorBasedPackageQueue
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:
• com.ptc.core.percol.collectorBasedRefreshInBackground — Specifies whether to enable background refreshing of collector-based package collections. The default is false. If set to true, collector-based package collectors refresh as a background process rather than a foreground process.
• com.ptc.core.percol.numBackroundRefreshQueues — Specifies how many queues run simultaneously when background refreshing of collector-based package collections is enabled. The default is 2 (named CollectorBasedPackageQueue1 and CollectorBasedPackageQueue2). If set to 3 or greater, additional queues are added and numbered sequentially.
• com.ptc.core.percol.backgroundRefreshCollectorLimit — Specifies how many objects can be included in a package collection when it is refreshed in the background. The default is -1, which sets background refreshing to the same limit as the foreground (determined by the com.ptc.core.collectionsrv.engine.limitDependencyTracing property). If set to 1 or greater, the limit is applied to package collections when they are refreshed in the background.
commonScheduleQueue
 |
This queue replaces the CleanUpScheduleQueue, MarkForDeleteQueue, PagingScheduleQueue, PurgeOrphanedEffAuditsQueue, and StatisticsScheduleQueue queues.
|
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:
• LicenseGroupMembershipLinks queue entries are scheduled to synchronize the participants in the View and Print Only license group with the View and Print Only Licenses table.
By default, a queue entry of this type is scheduled to run every midnight (0:00 AM GMT). The run time of the entry can be configured using the wt.org.CreateLicenseGroupMembershipLinkWeeklyQueueTime and the wt.org.CreateLicenseGroupMembershipLinkDayOfWeek properties.
|
|
Depending on when changes to group membership occur in relation to the scheduled run time of the entry, it can take up to one day for the View and Print Only Licenses table to reflect the membership change.
|
• StandardRecentlyVisitedService queue entries are created to remove the oldest items from all recently visited lists when the total number of list items exceeds the value specified for the wt.recent.objectStackSize property located in the wt.properties file. The default value for this property is 100.
A queue entry of this type is scheduled to run at midnight (0:00 AM GMT) the first time the StandardRecentlyVisitedService is started. Every time the queue task runs, it re-schedules itself to run again at midnight (0:00 AM GMT) on the following day.
• StandardPurgeService queue entries are created to cleanup canceled purge jobs. Queue entries of this type are only created when the wt.queue.executeQueues property is set to true. By default this property is set to true.
A queue entry of this type is scheduled to run every midnight (0:00 AM GMT). When the queue task runs it deletes cancelled purge jobs older than a day and which also have a status of Awaiting preview.
|
|
Purge jobs with a status of Awaiting preview are not visible to users viewing the Queue Management user interface.
|
• StandardCollectionService queue entries are created to disable queries with invalid criterion. This queue entry is only created when the both the wt.queue.executeQueues and wt.dataops.objectcol.cleanUpEnabled properties are set to true. By default, both of these properties are set to true.
A queue entry of this type is scheduled to run at midnight (0:00 AM GMT) once every seven days. It disables queries with invalid criterion. For example, it would disable a query that has a folder reference that has been deleted. Disabled queries are not visible to users viewing the Queue Management user interface.
• MarkForDeleteQueue entries are used by Windchill ProjectLink to implement the marking of projects and their contents as deleted. When a project is marked as deleted (using the Delete action), it no longer appears in any project member's My Projects list. The marking process is done in the background to improve user response time.
The system automatically sends a notification to the project managers group if the deletion of a project fails. The notification includes the exception message that caused the failure. The project manager should investigate the reason for the failure, correct it, and reattempt a project deletion by selecting the project Delete action again.
You should periodically check the commonScheduleQueue for failed MarkForDeleteQueue entries. If an entry has a failed status, the only action needed is to remove it from the queue.
• PagingScheduleQueue entries are used by Local Search to clean up temporary results that are stored in the database. The results are associated with search requests of each user. There is only one entry regardless of the number of users executing Local Search.
A failed entry means that the temporary results will not be cleaned up and may impact performance if the data grows too large. If the commonScheduleQueue queue is able to successfully create a new entry, then a subsequent execution will clean up all data (including the data from previous attempts).
You should check the commonScheduleQueue queue each day for failed PagingScheduleQueue entries to ensure that it the temporary results stored in the database are being cleaned up. Intermittent failures are not critical because the successful processing will clean up all data from previous failures. However, all failures should be investigated and reported through PTC Technical Support.
• PurgeOrphanedEffAuditsQueue entries are used by the Effectivity service to clean up audit objects.
Effectivity audit objects are created to track the creation and factual deletion of effectivity objects. A factual deletion means that an effectivity record is marked as deleted, but is retained as historical information. When effectivity objects are actually deleted, audit objects can become unreferenced, thus, having no further purpose. Checking for corresponding audit objects each time that an effectivity object is actually deleted is time consuming; therefore, this non-urgent clean up is done on a scheduled basis (by default, once a day). To change the schedule for the cleanup, change the interval time set in the wt.eff.EffChangeAudit.purgeInterval property, which is located in the wt.properties file. Express the interval time in minutes; the default value is 1440 minutes (one day).
|
|
If the value of the wt.eff.EffChangeAudit.purgeInterval property is set to zero or a negative value, the cleanup is not performed.
|
Failed PurgeOrphanedEffAuditsQueue entries mean an attempt to query for and delete the audit items has failed. Checking for failed PurgeOrphanedEffAuditsQueue entries is not needed on a regular basis. Each queue entry has identical functionality; therefore, if failed entries are noticed, they can be deleted (since they will be replaced by future ones). If the problem occurs chronically, check the system configuration and consider filing a problem report with PTC Technical Support. Also, since the Effectivity service is programmed to create this queue on startup (if it does not exist), a problematic instance of the queue can simply be deleted, along with all of its entries (regardless of their status).
• StatisticsScheduleQueue entries are used by the subtype/attribute query service to gather statistics related to global attributes (previously known as IBAs). These statistics are used when optimizing queries.
A failed queue entry implies that statistics were not collected. If statistical data is not up-to-date, then the soft type/attribute query performance may not be optimized.
The frequency for gathering the statistics is controlled by the com.ptc.core.query.optimize.statisticsBasedRankGenerator.queueInvokeTime property setting. The default is once a day. See properties.html for details.
LicenseScheduleQueue
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:
• synchronizeLicense — Synchronizes Windchill with PTC backend system to check for changes in license entitlements. The queue entry of this type is scheduled to run every 24 hours.
• createLicenseGroupMembershipLinks — Populates membership link table with license group members. The queue entry of this type is scheduled to run every midnight (0:00 AM GMT)
• UpdateFeatureLicenseCache — Checks for valid licenses and updates License Information table every midnight (0:00 AM GMT).
ContentControlQueue
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.
CtScheduleQueue
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.
dataMonitorProcessingQueue
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.
dataMonitorScheduleQueue
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.
DataSharingQueue
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.
DeleteCompletedWorkItemsQueue
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).
DigestNotificationQueue
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.
DTODeliverablesQueue
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.
DTOOffPeakQueue
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.
EMailQueue
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.
forumEventPropogationQueue
The forumEventPropogationQueue is used by Discussion Forums to delete the following objects:
• Discussion Topics (wt.workflow.forum.DiscussionTopic)
• Discussion Posting and replies (wt.workflow.forum.DiscussionPosting)
• Attached content to Discussion Postings (wt.workflow.notebook.Bookmark)
Failed queue entries can mean one of the following:
• A topic in a Discussion Forum has not been successfully deleted.
• A posting or a reply to a posting in the Discussion Forum has not been successfully deleted.
• An attachment to a posting has not been successfully deleted.
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
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.
IXRepositoryQueue
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.
NotificationQueue
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:
• Email subscriptions/notifications
• Object Listener subscriptions/notifications
These are subscriptions that can be created where the subscription "recipient" is a Windchill object that implements the wt.notify.ObjectSubscriptionListener interface. WfSynchRobot is one of these objects. Additionally, the Discussion Forum, Discussion Topic and Discussion Posting interfaces implement this. Whenever these Object Listener subscriptions are satisfied, instead of an email being sent to a user, the notification service invokes a method on the subscription's ObjectSubscriptionListener "recipient" object and the object does whatever processing is desired.
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.
NotificationScheduleQueue
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.
PartsLinkQueue
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.
ProjectScheduleQueue
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.
PublisherQueues
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.
PublisherQueue Entries for Visualization Services
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:
• Default queue set: PublisherQueueL, PublishQueueM, PublisherQueueH, and PublisherQueue1
• CLASH queue set: PublisherQueueCLASHL, PublishQueueCLASHM, PublisherQueueCLASHH, and PublisherQueueCLASH1
• PRINT queue set: PublisherQueuePRINTL, PublishQueuePRINTM, PublisherQueuePRINTH, and PublisherQueuePRINT1
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:
• Publish jobs: publish.publishqueue.set.0.0 and publish publishqueue.priorities0.0
• Interference jobs: clash.publishqueue.set.0.0 and clash .publishqueue.priorities0.0
• Print jobs: print.publishqueue.set.0.0 and print .publishqueue.priorities0.0
|
|
Beginning at Windchill 10.2, PTC has changed the location of the wvs.properties and wvs.properties.xconf files. These files have been moved from the $WT_HOME/codebase directory to the $WT_HOME/codebase/WEB-INF/conf directory. Be sure to make any necessary changes to your code to reflect this location change.
|
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.
|
|
The submission of print, publish, and interference detection jobs from L, M, or H queues to the numbered processing queues are supported when those numbered queues are in different background method servers.
|
PublisherQueue Entries for Windchill Packages
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
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.
WfPropagationQueue
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 default value for newly created WfPropagationQueue types is Pool, but you can set queue values to be either Pool or Process types
|
WfScheduleQueue
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.
WfUserWorkQueue
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 default value for newly created WfUserWorkQueue types is Pool, but you can set queue values to be either Pool or Process types.
|
WPSyncQueue
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.