【问题标题】:Tridion Publishing and Garbage CollectionTridion 发布和垃圾收集
【发布时间】:2012-06-22 11:09:08
【问题描述】:

我参考了之前的帖子 Tridion 2009 Template Publishing Failure,在该帖子中我解释说我们的系统在大规模发布期间显然是随机崩溃的。

我们正在使用 XSLTMediator,我们所有的模板都基于 TemplateBase 解决方案

我被告知该错误可能与垃圾收集/COM+ 相关 - 我认为这有点牵强,TemplateBase 解决方案明确实现了IDisposable,它应该处理所有 GC/COM+ 肮脏问题? (不像 VBScript 时代的 Set obj = Nothing to Avoid memory leaks)!

谢谢。

【问题讨论】:

  • 您能否提供事件查看器日志中的错误消息?另外,您的问题是“Tridion 发布如何进行垃圾收集或如何处理每个模板?”
  • 声明 IDisposable 不会自动修复任何问题。您的模板/中介代码必须正确实现 Dispose 并关闭它可能持有的任何资源。您可以考虑调用 .Close() 现代等效于将对象设置为 Nothing。但所有这些都只是陈述,你的问题是什么?
  • 中介代码实际上是 XsltMediator(它本身并不直接实现IDisposable)。在任何情况下都不需要担心非托管资源,所以 GC 应该正确地完成它的工作吗? TemplateBase 确实实现了它,这应该足够了吗?我不确定我的问题是什么,因为我不相信这个问题是由于没有实现IDisposable
  • 我当然很想知道实现 GC 的最佳实践是什么,以及 Tridion 本身如何处理模板(如果有人足以描述它的话)!

标签: tridion tridion2009


【解决方案1】:

听起来您需要进行一些深入的调试。有关此主题的高质量信息的一个来源是Tess Ferrandez' blog

【讨论】:

    【解决方案2】:

    这里有一些注意事项。

    1) 使用 Marshal.ReleaseComObject 来释放 Tridion COM 对象,但不能只调用一次,直到引用计数器达到 0。

    while (Marshal.ReleaseComObject(component) > 0);
    

    2) 不要将 COM 对象作为参数传递给函数。

    3) 不要尽可能多地声明或避免将 COM 对象声明为类中的字段。

    4) 考虑使用弱引用。弱引用会立即将您的对象标记为准备好进行 GC。由于 .Net GC 在后台线程中运行,并且我们不知道它何时执行,因此始终在所有弱引用中添加一个空值检查,以确保在使用它之前您的对象仍然存在,以防万一已经收集了,你需要再次实例化弱引用。

    【讨论】:

    • XSLTMediator 与模块化模板一起使用,因此将使用的 API 是 TOM.NET,它不会给您 RCW。即使是这样,使用 Marshal.FinalReleaseComObject() 也可以省去您自己编写该循环的代码。在这种情况下,弱引用不会对您有太大帮助。如果您再次需要该对象,只需在模板的生命周期内通过强引用来保持它。真的!如果您将对象推送到某种长期缓存中,弱引用可能是有意义的,但您为什么要这样做呢?
    • TOM.NET 对象(如 Engine、Session)仍在幕后使用互操作,因此将它们作为扩展对象的一部分传递给 XSLT 中介可能会导致内存泄漏。根据我的经验,将对象在一种技术之间传递给另一种技术,如 .Net 和 COM(MSXML 解析器)可能会导致内存泄漏,这就是弱引用出现迫使它释放的原因。
    • 但是弱引用不会强制释放任何东西。如果您的强引用超出范围,则具有相同的效果。弱引用只有在您有意保持对象“可访问”时才有意义(但准备让它被释放并处理后果)。这可能不是模板中的场景。
    猜你喜欢
    • 1970-01-01
    • 2012-03-21
    • 2013-01-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多