2012-06-22 1 views
-2

Я ссылаюсь на предыдущее сообщение Tridion 2009 Template Publishing Failure, где я объяснил, что наша система рушилась, по-видимому, случайно во время массового издания.Tridion Publishing and Garbage Collection

Мы используем XSLTMediator & все наши шаблоны основаны вокруг TemplateBase решения

Я советовала, что ошибка может быть связана с Garbage Collection/COM + - Я думаю, что это немного красной сельди, решение TemplateBase явно реализует IDisposable, которое должно заботиться обо всех проблемах с GC/COM +? (в отличие от дней VBScript Set obj = ничего, чтобы избежать утечек памяти)!

Спасибо.

+2

Можете ли вы предоставить сообщение об ошибке из журналов просмотра событий? Кроме того, возникает вопрос: «Как публикация Tridion делает сборку мусора или как каждый шаблон удаляется?» –

+2

Объявление IDisposable ничего не исправит автоматически. Ваш код шаблона/посредника должен будет правильно реализовать Dispose ** ** и закрыть любые ресурсы, на которые он может удерживать. Вы можете рассмотреть возможность вызова .Close() современного эквивалента времени для установки объекта Nothing. Но все это просто заявления, в чем ваш вопрос? –

+0

Код посредника - это, фактически, XsltMediator (который сам не реализует 'IDisposable' непосредственно). В любом случае нет неуправляемых ресурсов, чтобы беспокоиться о том, что GC должен правильно выполнять свою работу? TemplateBase действительно реализует его, которого должно быть достаточно? Я не уверен, в чем мой вопрос, так как я не уверен, что эта проблема сводится к тому, чтобы не реализовывать 'IDisposable' – mpaton

ответ

2

Похоже, что вам нужно выполнить некоторую углубленную отладку. Одним из источников высококачественной информации по этой теме является Tess Ferrandez' blog

-2

Вот некоторые соображения.

1) Использование Marshal.ReleaseComObject освободить Tridion COM-объектов, но не только один раз назвать его, пока счетчик ссылок не достигнет 0.

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

2) Не пропустите COM-объектов в качестве параметров функций.

3) Не объявляйте и не избегайте столько, сколько сможете, чтобы объявлять COM-объекты в качестве полей в вашем классе.

4) Рассмотрите возможность использования WeakReferences. Слабая ссылка будет немедленно отмечать ваш объект как готовый к GC. Поскольку .Net GC работает в фоновом потоке, и мы точно не знаем, когда он будет выполнен, всегда добавляйте нулевую проверку во всех ваших слабых ссылках, чтобы убедиться, что ваши объекты все еще живы, прежде чем вы ее используете, в случае, если это уже собранный, вам нужно будет снова создать слабую ссылку.

+0

XSLTMediator используется с модульными шаблонами, поэтому API, который будет использоваться, - TOM.NET, который не собирается передавать вам RCW. Даже если бы это было сделано, использование Marshal.FinalReleaseComObject() спасло бы вас, чтобы запрограммировать этот цикл самостоятельно. Слабые ссылки не помогут вам в этом сценарии. Если вам нужен объект снова, просто держите его с сильной ссылкой в ​​течение всего срока действия вашего шаблона. В самом деле! Слабые ссылки могут иметь смысл, если вы толкаете объекты в какой-то долгоживущий кеш, но зачем вам? –

+0

Объекты TOM.NET, такие как Engine, Session, по-прежнему используют interops за кулисами, поэтому передача их в XSLT-посредник как часть объекта расширения может привести к утечкам памяти. По моему опыту, передача объектов между одной технологией в другую, например .Net и COM (MSXML Parser), может привести к утечкам памяти, поэтому на снимках появляются слабые ссылки, заставляющие ее выпускать. –

+0

Но слабая ссылка не заставляет выпускать что-либо. Если ваши сильные ссылки выходят из сферы действия, это имеет тот же эффект. Слабая ссылка интересна, если вы намеренно хотите сохранить объект «достижимым» (но готовы разрешить его устранять и иметь дело с последствиями.) Это, вероятно, не сценарий в шаблоне. –