Tridion事件系统超时

我目前正在运行Tridion 2011 SP1

我正在编写一些在页面发布时运行的代码。它循环遍历页面中的每个组件模板，获取组件并将各个字段写入XML文档。对于包含多个组件模板的页面或包含多个字段的组件，此过程可能需要一段时间才能运行。如果这个过程需要30秒以上，我会得到一个错误

The operation performed by thread "EventSystem0" timed out.

Component: Tridion.ContentManager
Errorcode: 0
User: NT AUTHORITY\NETWORK SERVICE

接着是另一个

Thread was being aborted.


Component: Tridion.ContentManager
Errorcode: 0
User: NT AUTHORITY\NETWORK SERVICE

StackTrace Information Details:
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
   at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object[] parameters, Object[] arguments)
   at System.Delegate.DynamicInvokeImpl(Object[] args)
   at Tridion.ContentManager.Extensibility.EventSubscription.DeliverEvent(IEnumerable`1 subjects, TcmEventArgs eventArgs, EventPhases phase)

我相信我有三个选择

1。增加超时时间

这似乎是一个懒惰的解决方案，只会隐藏问题。无法保证超时问题不会再次发生。我也不确定超时值存储在哪里（我尝试过在Tridion Content Manager.msc管理单元中更改一些值，但没有成功）

2。在实际的事件处理程序例程中少做一些事情，让一个单独的流程来完成所有繁重的工作

这似乎也不是正确的解决方案。我真的希望将所有事件处理程序代码都放在一个地方。对于我们的live 5.3安装，我们有一个这样的解决方案，要维护它是一个噩梦（它非常旧，编写得很糟糕）

3。使我的代码更高效

我的组件有许多字段，如果它们是组件链接，我的代码必须深入研究每个字段。我猜因为Tridion对象的属性是延迟加载的，所以我访问的每个属性都有一个对API/数据库的调用。检索一个属性平均需要0.2秒，在访问多个属性时很快就会堆积起来。如果有一种方法可以在一次调用中检索所有属性，这将非常有用

---

有什么想法吗？

您是否考虑过异步运行事件？可以通过更改以下行来执行此操作：

EventSystem.Subscribe<IdentifiableObject,TcmEventArgs(....)

---

< >订阅> <>你可以考虑的一件事是使用组件的<>代码>毒素（）/<代码>方法，从XML DOM获取你的值，而不是使用Trdion API。这通常要快得多，您可以使用XSLT或Linq“遍历”字段

---

如果您真的只对字段感兴趣，那么只需使用

.Content

（和

.Metadata

）属性，并且再次使用Linq或XSLT或任何您想要解析xml的技术（可能除外）。

您只是在做大量处理，这需要时间。也许有技术上的修正，但在这种情况下首先要做的是回到为什么和什么？发布页面从根本上讲就是呈现要为该页面输出的HTML和二进制文件。需要多长时间

---

那么你能告诉我们你为什么要这么做吗？也许可以将部分工作转移到其他地方，而不影响良好的设计。如果我们知道目的是什么，也许我们可以提供更多帮助。

如果您确实需要处理时间，那么我认为您应该编写一个web服务来执行您需要的操作，您可以从事件处理程序调用它。这也不会对用户体验造成太大影响（对于同步事件处理程序而言）。

SDL客户支持建议我增加超时时间。虽然不是一个很好的解决方案，但它是唯一可用的解决方案。这样做

在安装content manager的服务器上，打开

Tridion.ContentManager.config

，该文件应位于content manager根目录的

config/

子目录中，默认为

C:\Program Files\Tridion\或C:\Program Files（x86）\Tridion\

查找

节点

将

threadtimeout

值（以秒为单位）增加到更高的值（我将其设置为120）

保存

Tridion.ContentManager.config

并重新启动

Tridion ContentManager服务主机

服务

---

可提供进一步的文件。它确实需要用户名和密码才能访问。

谢谢您的回复。我确实试过了，但仍然出现超时错误。我认为这与调用Subscribe/subscribebeasync方法的反射方法中的超时有关。我认为这不太可能，因为Subscribe调用不是在事件发生时完成的，而是在Tridion启动时完成的。另一种解释是，您从事件代码进行的某个Tridion API调用正在超时（而不是事件代码本身）。对不起。我没有解释清楚。我的意思是通过反射类调用处理事件的方法（TcmEventHandler eventHandler）。所以在我的例子中，我有一个被System.RuntimeMethodHandle.InvokeMethod（…）调用的方法PagePublishedCommittedHandler，当PagePublishedCommittedHandler在30秒内没有返回时，它抛出异常。也许我错了？补充一下。我已经分析了我的代码，一切都运行良好，没有一个巨大的超时。这是对API的0.2秒的小调用，总计超过30秒。@Kevin如果我理解正确，您正在试图找到指向当前组件的链接（gui中的“where used”（在何处使用）功能。这是出了名的慢。是否可以重写您的逻辑，从另一端开始，即从链接器组件而不是从链接器开始？检查Tridion事件日志中是否有任何异常。您知道确切的超时是什么吗？我正在大量调用API以获取组件。）对一个组件进行调用。每个调用平均需要0.2秒。假设我有一个包含20个组件的页面，其中每个组件都有10个链接组件，这意味着对Tridion API进行200次调用，以获取我需要的所有信息。200次调用*0.2秒是40秒。似乎有30秒的超时限制，因此引发了一个异常。这就是一个有趣的问题凯文。我担心获得数百个组件只是需要时间。增加超时听起来是你最糟糕的选择。正如我最近在推特上所说，它改变了“th

EventSystem.SubscribeAsync<IdentifiableObject,TcmEventArgs(....)