预设后台队列
以下各节中介绍了安装 Windchill 解决方案时建立的队列。安装可选产品时，可建立其他队列。这些队列被描述为产品说明的一部分。而例如，用于文件存储的队列在出厂设置的外部存储后台队列中进行介绍，用于内容复制的队列在出厂设置的复制后台队列中进行介绍。
CollectorBasedPackageQueue
CollectorBasedPackageQueue 可使基于收集器的包集合作为后台进程刷新。此选项可通过将集合移至后台来为前台进程释放可用资源。默认情况下，此选项是禁用的。以下特性对此队列很有用：
• com.ptc.core.percol.collectorBasedRefreshInBackground - 指定是否对基于收集器的包集合启用后台刷新。默认值为 false。如果设置为 true，基于收集器的包收集器将作为后台进程而非前台进程进行刷新。
• com.ptc.core.percol.numBackroundRefreshQueues - 指定对基于收集器的包集合启用后台刷新时同时运行队列的数量。默认值为 2 (队列名为 CollectorBasedPackageQueue1 和 CollectorBasedPackageQueue2)。如果设置为 3 或更大，则会添加其他队列并按顺序编号。
• com.ptc.core.percol.backgroundRefreshCollectorLimit - 指定在后台刷新包集合时，一个包集合中可以包含的对象数量。默认值为 -1，可将后台刷新限制设置为与前台相同 (由 com.ptc.core.collectionsrv.engine.limitDependencyTracing 特性定义)。如果设置为 1 或更大，限制将在包集合在后台刷新时应用于包集合。
commonScheduleQueue
 |
此队列将替换 CleanUpScheduleQueue、MarkForDeleteQueue、PagingScheduleQueue、PurgeOrphanedEffAuditsQueue 和 StatisticsScheduleQueue 队列。
|
commonScheduleQueue 用于多种低容量的队列条目。这些低容量条目需要有限的资源，并且通常仅运行一次或偶尔运行。将这些队列条目合并为 commonScheduleQueue 可释放系统资源，从而集中处理高容量队列。以下列表说明了每个 commonScheduleQueue 条目类型：
• LicenseGroupMembershipLinks 队列条目将使“仅查看和打印许可证”组中的参与者与“仅查看和打印许可证”表格同步。
默认情况下，该类型的队列条目将在每个午夜 (0:00 AM GMT) 运行。该条目的运行时间可使用 wt.org.CreateLicenseGroupMembershipLinkWeeklyQueueTime 和 wt.org.CreateLicenseGroupMembershipLinkDayOfWeek 特性进行配置。
|
|
根据组成员资格变更所发生的时间与条目的已安排运行时间之间的关系，最多可能需要一天的时间来使“仅查看和打印许可证”表格反映成员资格变更。
|
• 系统将创建 StandardRecentlyVisitedService 队列条目，以便当列表项总数超过为 wt.recent.objectStackSize 特性 (位于 wt.properties 文件中) 所指定的值时，从所有最近访问的列表中移除最旧项。此特性的默认值是 100。
在 StandardRecentlyVisitedService 首次启动时，此类型的队列条目将被安排在午夜 (0:00 AM GMT) 运行。每当队列任务运行时，其都会将自身重新安排在第二天的午夜 (0:00 AM GMT) 再次运行。
• 系统将创建 StandardPurgeService 队列条目来清理已取消的清除作业。只有在 wt.queue.executeQueues 特性被设置为 true 时，系统才会创建该类型的队列条目。该特性在默认情况下被设为 true。
该类型的队列条目将被安排在每个午夜 (0:00 AM GMT) 运行。当队列任务运行时，其会删除已超过一天并具有“等待”预览状态的已取消的清除作业。
|
|
具有“等待”预览状态的清除作业对于查看“队列管理”用户界面的用户不可见。
|
• 系统将创建 StandardCollectionService 队列条目以禁用具有无效条件的查询。只有将 wt.queue.executeQueues 和 wt.dataops.objectcol.cleanUpEnabled 特性都设置为 true 时，才能创建该队列条目。在默认情况下这些特性都被设为 true。
该类型的队列条目将每隔七天在午夜 (0:00 AM GMT) 运行一次。它禁用带有无效条件的查询。例如，它将禁用具有已删除的文件夹参考的查询。已禁用的查询对于查看“查询管理”用户界面的用户不可见。
• MarkForDeleteQueue 条目由 Windchill ProjectLink 用于将项目及其内容标记为已删除。项目被标记为已删除后 (通过“删除”操作)，它将不再出现在任何项目成员的“我的项目”列表中。标记过程在后台完成以缩短用户响应时间。
如果删除项目失败，则系统自动向项目经理组发送通知。通知包括导致失败的例外消息。项目经理应调查失败原因、进行修正然后通过再次选择项目“删除”操作重试项目删除。
您应定期检查 commonScheduleQueue 中是否存在失败的 MarkForDeleteQueue 条目。如果条目具有失败状态，则所需的唯一操作即是从队列删除它。
• PagingScheduleQueue 条目将由“本地搜索”用来清理存储在数据库中的临时结果。这些结果与每个用户的搜索请求关联。无论执行“本地搜索”的用户的数量为何值，都将只有一个条目。
失败条目表示临时结果将无法被清除，并且如果数据变得太大可能影响性能。如果 commonScheduleQueue 队列能够成功创建新条目，则后续执行将清理所有数据 (包括来自先前尝试的数据)。
您应每天检查 commonScheduleQueue 队列中是否存在失败的 PagingScheduleQueue 条目，以确保存储在数据库中的临时结果被清理。间歇性失败并非严重错误，因为成功的处理将清理先前失败中的所有数据。但是，您应通过“PTC 技术支持”调查和报告所有故障。
• PurgeOrphanedEffAuditsQueue 条目由“有效性服务”用来清理审计对象。
系统创建有效性审计对象来跟踪有效性对象的创建和事实删除。“事实删除”是指将有效性记录标记为已删除，但保留为历史信息。实际删除有效性对象后，审计对象变为未引用状态，因而不再有用。每次都检查相应的审计对象以确定实际删除了有效性对象会花费很多时间，因此，此项非紧急性的清理工作可按计划执行 (默认设置为每天一次)。要更改清理排程，请更改在 wt.eff.EffChangeAudit.purgeInterval 特性 (位于 wt.properties 文件) 中设置的间隔时间。间隔时间以分钟为单位，默认值为 1440 分钟 (一天)。
|
|
如果将 wt.eff.EffChangeAudit.purgeInterval 特性的值设置为零或负值，则不会执行清理操作。
|
失败的 PurgeOrphanedEffAuditsQueue 条目表示对审计项的查询和删除尝试已失败。无需定期检查失败的 PurgeOrphanedEffAuditsQueue 条目。每个队列条目都具有相同的功能，因此，如果发现失败条目，可删除它们 (因为它们将由未来的条目取代)。如果此问题长期存在，请检查系统配置并考虑向 PTC 技术支持提出问题报告。而且，由于将有效性服务设计为在启动时创建此队列 (若不存在此队列)，因此完全可以删除队列的问题实例及其所有条目 (无论它们的状态如何)。
• StatisticsScheduleQueue 条目由子类型/属性查询服务使用，目的是收集与全局属性 (以前称为 IBA) 相关的统计信息。优化查询时会用到这些统计信息。
失败队列条目表示未收集统计信息。如果统计数据不是最新的，则无法优化可变类型/属性查询性能。
收集统计信息的频率由 com.ptc.core.query.optimize.statisticsBasedRankGenerator.queueInvokeTime 特性设置控制。默认设置为每天一次。有关详情，请参阅 properties.html。
LicenseScheduleQueue
LicenseScheduleQueue 为不可变队列，并用于与许可证相关的队列条目。由于此队列是不可变的，因此您无法对此队列或其条目执行停止、禁用、编辑、重置或删除等操作。这些操作在 LicenseScheduleQueue 的队列管理用户界面中处于隐藏状态。仅 PTC 有权创建和修改许可证相关队列。
下表对 LicenseScheduleQueue 中的各类条目进行了说明：
• synchronizeLicense - 将 Windchill 与 PTC 后台系统同步，以便检查许可证授权的变化。此类队列条目被安排每 24 小时运行一次。
• createLicenseGroupMembershipLinks - 以许可证组成员填充成员资格链接表。此类队列条目被安排在每个午夜 (0:00 AM GMT) 运行。
• UpdateFeatureLicenseCache - 每个午夜 (0:00 AM GMT) 检查有效许可证并更新许可证信息表格。
ContentControlQueue
ContentControlQueue 在启用包的内容控制功能后使用。用户可通过内容控制功能从“文件表格”中指定哪些内容文件应包括在包交付中，方法是在“包内容”表格的“操作”菜单中选择“选择文件”。
内容控制功能需要使用基于包类型的特性中所述的基于类型的特性文件显式启用。
当包的内容控制功能已启用并且包已锁定时 (或者随后解锁)，队列中会添加一个新条目。相似地，通过“包内容”用户界面进行的任何包成员内容控制信息更改都会向队列中添加新的条目。当执行队列条目时，将保持包成员的内容控制数据。
CtScheduleQueue
CtScheduleQueue 在开启团队更新的自动安排后使用。
有关团队更新的自动安排的详情，请参阅同步团队和用户定义的组。
dataMonitorProcessingQueue
dataMonitorProcessingQueue 及 dataMonitorScheduleQueue 与 Windchill 报告数据监控器功能一起使用。执行数据监控器的已安排实例后，系统会向 dataMonitorProcessingQueue 添加一个条目。如果删除了数据监控器，则所有 dataMonitorProcessingQueue 条目在执行完毕后均会被删除。dataMonitorProcessingQueue 状况显示在数据监控器信息页面“已执行的报告”表格的“状况”列中。
dataMonitorScheduleQueue
dataMonitorScheduleQueue 及 dataMonitorProcessingQueue 与 Windchill 报告数据监控器功能一起使用。创建数据监控器后，系统会针对数据监控器执行操作的每个已安排实例向 dataMonitorScheduleQueue 添加一个条目。执行已安排实例后，系统会向 dataMonitorProcessingQueue 添加一个条目。删除某个数据监控器后，该数据监控器的所有 dataMonitorScheduleQueue 条目均会被删除。dataMonitorScheduleQueue 状况显示在“数据监控器”表格的“状况”列中。
DataSharingQueue
当上下文之间存在数据共享时，系统会使用 DataSharingQueue。在某些情况下，共享状况的更新会涉及大量的处理工作。例如，如果共享某个文件夹，则所有入夹对象也相应共享。此队列用于在后台处理这一类更新。使用此队列可使用户响应时间不受共享更新处理的影响。
DeleteCompletedWorkItemsQueue
DeleteCompletedWorkItemsQueue 会删除特定上下文中特定参与者的已完成工作项。在删除工作项之前，DeleteCompletedWorkItemsQueue 会读取首选项。首选项值可以为数字、ALL 或 NO。如果值为 NO，将不删除已完成的工作项。如果为 ALL，则删除所有已完成的工作项。如果值为数字，则表示最近完成工作中未删除的项数。其余工作项将被删除。只有当超出的完成工作项的数量为指定首选项的两倍时，才会对完成的工作项执行删除操作。例如，如果首选项为 10，则只有在超出的工作项的数量为 20 时才会对完成的工作项执行删除操作。请知悉，只有当工作项的父进程为 CLOSED 时，该工作项才会被删除。不删除完成的项目工作项。
该首选项的默认值为 NO。
删除完成的工作项 (由首选项决定) 时，此队列中的失败条目会导致操作失败。
DigestNotificationQueue
DigestNotificationQueue 由通知服务用来排列发送电子邮件的请求。会对请求进行排队，以根据排程针对要传送的通知订阅发送摘要通知电子邮件，而并不会立即发送。用户可以在订阅对象时利用订阅用户界面选择传送方法。可在“站点”级别或“组织”级别设置在订阅对象时，从而设置摘要通知的传送时间。“组织”级别首选项适用于组织中的用户，“站点”级别首选项适用于“组织”级别首选项未涵盖的用户。针对每个唯一的首选项值在 DigestNotificationQueue 上对请求进行列队，以安排摘要通知电子邮件的传送，而这些请求将摘要通知电子邮件传送给由该请求表示的首选项所涵盖的所有用户。
DTODeliverablesQueue
DTODeliverablesQueue 处理可交付结果的请求，即用户请求从可配置部件 (原通用部件) 生成可交付结果。请求会被放入队列中进行处理，并在完成后将结果发送给用户。唯一支持出厂设置的可交付结果生成器为 BOMMaker，该生成器可生成各种部件结构。通常情况下，BOMMaker 运行速度较快。还有其他可交付结果生成器。另外，客户还可以编写自己的可交付结果生成器，但这也许会花费较长时间 (分钟或小时)。在这些情况下，DTODeliverablesQueue 最为有用。
DTOOffPeakQueue
DTOOffPeakQueue 处理应在非高峰期间 (例如晚间) 运行的运行任务。这些任务长时间运行且没有优先级。例如，一项任务可能会搜索可配置部件的潜在变形，并将其作为变形进行附加。
MVGConfigurableQueue
MVGConfigurableQueue 用于处理来自“配置多个变型”的请求。请求将放入队列以进行处理。此队列将处理总体请求和变型规范生成进程，变型生成进程通过 DTODeliverablesQueue 单独管理。由于这些任务的运行时间可能很长，因此也可以将队列配置为在非高峰时段运行。
EMailQueue
EMailQueue 由邮件服务用来排列发送电子邮件的请求。向邮件服务请求发送电子邮件时，将在 EMailQueue 上对该请求进行列队。在队列中处理该请求时，便会发送电子邮件。邮件服务还会使用队列来重新尝试发送那些发送失败的电子邮件。请求发送电子邮件失败时，邮件服务需要在邮件发出的一段时间后对该请求重新进行处理。默认情况下，发送电子邮件的请求在 24 小时之内有效。如果邮件服务未在有效时间内成功处理此请求，则邮件服务将放弃尝试针对该请求发送电子邮件。
forumEventPropogationQueue
“讨论论坛”使用 forumEventPropogationQueue 来删除以下对象：
• 研讨主题 (wt.workflow.forum.DiscussionTopic)
• 研讨电子公告和回复 (wt.workflow.forum.DiscussionPosting)
• 研讨电子公告附加内容 (wt.workflow.notebook.Bookmark)
失败的队列条目指示以下一种情况：
• 未成功删除“讨论论坛”的某一主题。
• 未成功删除“讨论论”中的电子公告或电子公告的回复。
• 未成功删除电子公告的附件。
每天都应检查此队列以确保该队列工作正常。如果对“讨论论坛”的使用频率较高，可能需要经常检查队列。对于每个失败的队列条目，将队列条目状态重置为就绪。
建立索引队列和成批建立索引队列
“索引队列”和“成批索引队列”是在安装 Windchill Index Search 时设置的可选队列。在索引过程中要用到这些队列。应定期检查“索引队列”和“成批索引队列”是否存在失败条目。
如果某个索引队列条目处于“严格的”状态，请确保正确配置了索引和搜索引擎且 Windchill Index Search 软件正在运行。然后将队列条目重置为“就绪”。重置队列条目会重新启动索引进程。
IXRepositoryQueue
包“标准接收的交付服务”可利用 IXRepositoryQueue 来为导入创建对象信息。此信息将在包导入期间用于创建批处理。
用户上传包含包数据的 ZIP 文件时，由 ReceivedDeliveryChunkInfo (ZIP 信息) 组成的队列条目将添加到此队列中。执行队列条目时，将针对 ZIP 中的对象创建元数据信息。
NotificationQueue
NotificationQueue 由通知服务用来排列生成和发送通知 (基于策略和订阅的通知) 的请求。
通知服务支持两种预定/通知：
• 电子邮件订阅/通知
• 对象监听程序预定/通知
这些是可创建的预定，其中的预定 "recipient" 是实现 wt.notify.ObjectSubscriptionListener 界面的 Windchill 对象。WfSynchRobot 属于这些对象之一。此外，“讨论论坛”、“讨论主题”及“讨论电子公告”界面也会使用这些对象。只要满足这些“对象监听程序”订阅，通知服务便会调用订阅的 ObjectSubscriptionListener "recipient" 对象上的方法 (而不向用户发送电子邮件)，而该对象会执行所有所需处理。
NotificationQueue 用于电子邮件预定和对象监听程序预定；因此，只有为 WfSynchRobots 启动 NotificationQueue 才能得到通知，这样它们可以在满足预定时执行所需处理。停止 NotificationQueue 会阻止电子邮件通知的发送，并能够阻止对象监听程序订阅者发挥作用。
NotificationScheduleQueue
NotificationScheduleQueue 由通知服务使用。请求排队等待终止订阅。订阅 UI 允许用户设置订阅的截止日期，排列的请求在到期时删除订阅。
PartsLinkQueue
PartsLinkQueue 是可选队列，在安装 Windchill Classification 时设置。此队列由 Windchill Classification 服务用来发布已被分类到 PartsLink Server 的部件。
应定期检查 PartsLinkQueue 是否存在失败条目。如果存在失败状态，则所需的唯一操作是将队列条目重置为“就绪”。
ProjectScheduleQueue
“典型项目管理”使用 ProjectScheduleQueue 根据错过最后期限、接近最后期限和超过最后期限发送事件。
无需定期检查此队列，此队列中发生失败的可能性极低。如果有未发送项目管理最后期限消息的投诉，则应检查此队列。但是，通知失败更多由电子邮件服务器的问题所导致。
PublisherQueues
会创建 PublisherQueues，供“可视化服务”用来管理可视化数据的发布和打印，以及相关工程计算，如干涉检测。此外，当包压缩处理进程中需要内容同步时，Windchill 包会向 PublisherQueues 中添加条目，本主题稍后将对此进行介绍。
可视化服务的 PublisherQueue 条目
在可视化服务中 CAD 数据通常在检入后发布。这样，许多客户站点便可大量使用这些队列来执行长时间 (可能是几小时) 运行的作业。每个 PublisherQueue 都遵循 PublishQueue<queueset>L/M/H 或 PublishQueue<queueset>N 的命名约定，其中 L/M/H 代表低/中/高属性，而 N 是从 1 开始的连续整数。具有相同 queueset 的队列被称为队列集。以空字符串作为名称的默认队列集始终存在；所有附加队列集必须由 wvs.properties 中的 publish.publishqueue.setnames 特性声明。以下队列集和队列在出厂设置时创建：
• 默认队列集：PublisherQueueL、PublishQueueM、PublisherQueueH 和 PublisherQueue1
• CLASH 队列集：PublisherQueueCLASHL、PublishQueueCLASHM、PublisherQueueCLASHH 和 PublisherQueueCLASH1
• PRINT 队列集：PublisherQueuePRINTL、PublishQueuePRINTM、PublisherQueuePRINTH 和 PublisherQueuePRINT1
根据作业类型、提交作业的方式及数据类型将所有提交的 WVS 作业添加到优先级队列中 (名称以 L、M 或 H 结尾)。此流程由 wvs.properties 中的特性设置控制。有关详情，请参阅 wvs.properties.xconf 中的以下特性：
• 发布作业：publish.publishqueue.set.0.0 和 publish publishqueue.priorities0.0
• 干涉作业：clash.publishqueue.set.0.0 和 clash .publishqueue.priorities0.0
• 打印作业：print.publishqueue.set.0.0 和 print .publishqueue.priorities0.0
|
|
PTC 更改了 wvs.properties 和 wvs.properties.xconf 文件的位置。这些文件已从 $WT_HOME/codebase 目录移至 $WT_HOME/codebase/WEB-INF/conf 目录。请确保对代码作出所有必要的变更，以反映此位置的变更。
|
L、M 和 H 优先级队列中正在执行的作业在相同队列集中查找可用编号队列 (名称以连续数字 N 结尾)。如果找到某个队列，该作业会将 WVS 作业提交到该队列，立即执行该作业。默认情况下，只会为每个队列集创建一个编号队列。其他发布队列 (例如 PublisherQueue2、PublisherQueue3、PublisherQueueCLASH2 等) 可使用 Windchill“队列管理”实用程序进行创建以获得可伸缩性。
存储在队列条目中的对象为 com.ptc.wvs.server.publish.PublishJob、com.ptc.wvs.server.publish.ClashJob 或 com.ptc.wvs.server.publish.PrintJob 对象。您可以在“WVS 作业监视器”中查看 WVS 作业的详情。如果作业失败，使用队列条目的日志信息 (显示在 WVS 作业监视器中) 来调查失败的原因。解决问题后，重新提交作业。
|
|
当已编号的队列位于不同的后台方法服务器中时，支持将打印作业、发布作业和干涉检测作业从 L、M 或 H 队列提交到这些已编号的队列。
|
Windchill 包的 PublisherQueue 条目
当导出并压缩 Windchill 包时，可将条目添加到其中一个默认的 PublisherQueues 中，如 PublisherQueue1。这些条目用于对要导出的所有 CAD 内容进行更新，以将与该内容相关的全部 Windchill 元数据更改包括在内。
要在导出并压缩包时将队列用于 CAD 内容同步，必须设置具体的包首选项。有关首选项的详情，请参阅设置包首选项。
如果包首选项设置为启用队列的使用，则使用的队列处理与可视化服务生成表示时使用的处理相同。存储在包队列条目中的对象是 com.ptc.wvs.server.publish.PublishJob 对象。因此，Windchill 包队列条目与可视化服务中的条目有相同的属性。相似地，您可以在“WVS 作业监视器”中查看作业的详情。如果作业失败，使用队列条目的日志信息 (显示在 WVS 作业监视器中) 来调查失败的原因。解决问题后，重复包导出操作。
RDImportExecutorQueue
RDImportExecutorQueue 用于处理接收的交付包的导入。对接收的交付启动“导入”操作后，含有接收的交付标识信息的条目将添加到此队列中。执行队列条目时，将触发接收的交付的导入。有关导入的信息，请参阅导入接收的交付文件。
根据要处理对象或文件的数目，导入接收的交付可能是个很长的过程。
WfPropagationQueue
工作流 (及其关联任务) 使用 WfPropagationQueue 将所有状态变更传播到“工作流”对象。这包括与那些状态变更关联的所有路由表达式和转变表达式。
当许多 Windchill 用户正同时完成工作流任务时，可能会大量使用工作流队列。此外，在创建使用生命周期 (反过来使用工作流) 的 Windchill 业务对象的场景中也可能频繁使用它们。
如果工作流队列的性能出现问题，可设置包括 WfUserWorkQueue 和 WfPropagationQueue 队列的队列池。WfPropagationQueue 队列在池中以 WfSharedPropagationQueue<n> 命名 其中 <n> 从 1 开始并针对每个附加队列以 1 递增。有关设置队列池的详情，请参阅队列池。
工作流队列中的失败条目表示某些对象未能正确处理。大多数情况下，失败工作流队列条目对应方法服务器日志中的堆栈追踪。通过检查方法服务器日志来分析队列条目失败以确定失败原因。有时，“队列管理”实用程序中所列出的消息足以确定失败的原因。
当与队列关联的工作流活动表现出执行不正常时，应检查工作流队列。此外，最好定期检查队列以清除出旧条目。
|
|
新创建的 WfPropagationQueue 类型的默认值是“合用”，但可将队列值设置为“汇聚”类型或“进程”类型。
|
WfScheduleQueue
WfScheduleQueue 由工作流 (及其关联任务) 用来排列所有定时的事件。最后期限检查具有最后期限设置的任意工作流对象，并且在此队列内执行基于表达式的“同步自动机”。
当许多 Windchill 用户正同时完成工作流任务时，可能会大量使用工作流队列。此外，在创建使用生命周期 (反过来使用工作流) 的 Windchill 业务对象的场景中也可能频繁使用它们。
工作流队列中的失败条目表示某些对象未能正确处理。大多数情况下，失败工作流队列条目对应方法服务器日志中的堆栈追踪。通过检查方法服务器日志来分析队列条目失败以确定失败原因。有时，“队列管理”实用程序中所列出的消息足以确定失败的原因。
当与队列关联的工作流活动表现出执行不正常时，应检查工作流队列。此外，最好定期检查队列以清除出旧条目。
WfUserWorkQueue
WfUserWorkQueue 由工作流 (及其关联任务) 用来实例化工作流自动机和执行工作流自动机操作。
当许多 Windchill 用户正同时完成工作流任务时，可能会大量使用工作流队列。此外，在创建使用生命周期 (反过来使用工作流) 的 Windchill 业务对象的场景中也可能频繁使用它们。
如果工作流队列的性能出现问题，可设置包括 WfUserWorkQueue 和 WfPropagationQueue 队列的队列池。WfUserWorkQueue 队列在池中以 WfSharedUserQueue<n> 命名，其中 <n> 从 1 开始并针对每个附加队列按 1 递增。有关设置队列池的详情，请参阅队列池。
工作流队列中的失败条目表示某些对象未能正确处理。大多数情况下，失败工作流队列条目对应方法服务器日志中的堆栈追踪。通过检查方法服务器日志来分析队列条目失败以确定失败原因。有时，“队列管理”实用程序中所列出的消息足以确定失败的原因。
当与队列关联的工作流活动表现出执行不正常时，应检查工作流队列。此外，最好定期检查队列以清除旧条目。
|
|
新创建的 WfUserWorkQueue 类型的默认值是“合用”，但可将队列值设置为“汇聚”类型或“进程”类型。
|
WPSyncQueue
WPSyncQueue 用于处理包导出操作。每次包压缩操作都会针对压缩进程的长度在 WPSyncQueue 上生成一个条目。当有大量对象或对象含有大量内容时，包压缩可能是个长时间运行的进程。
此外，当压缩进程中需要内容同步时，将在 PublisherQueues 中创建队列条目以使内容同步。如果受支持的 CAD 内容位于包中且内容同步已启用，则将进行内容同步。