Утечка памяти в WebSphere Portal, связанная с URI портала - PullRequest
Новая
       11

Утечка памяти в WebSphere Portal, связанная с URI портала

2 голосов
/ 18 января 2010

У меня приложение с утечкой кучи Java с приличной скоростью (400 пользователей оставляют 25% свободными через 2 часа ... после выхода из системы восстанавливается вся память), и мы определили элементы, вызывающие утечку памяти, как помещенные строки в сеансе, который создается самим порталом. Значения представляют собой закодированные URI портала (очень длинные строки с конечным кодом ... обычно размером около 19 КБ), и ключи кажутся семью (7) случайно сгенерированными символами с префиксом RES# (например, RES#NhhEY37).

Мы прошли через приложение, используя трассировку сеанса и отключая heapdumps, в результате чего было определено, что один из этих объектов создан и добавлен в сеанс почти на каждой странице ... фактически, кажется, что он включен каждая страница, которая представляет данные (это большинство страниц). Таким образом, это либо 1: 1 со страницами в целом, либо 1: 1 с формами.

Кто-нибудь сталкивался с подобной проблемой, как эта? Мы открываем тикет с IBM, но хотели бы также спросить это сообщество. Заранее спасибо!

Ответы [ 3 ]

1 голос
/ 02 апреля 2010

Фактическая проблема оказалась работающей в Portal.В частности, защита действий портала, которая предотвращает повторную отправку одного и того же действия, сохраняя при этом навигационные возможности портала.Существует кэш, который сохраняет результаты действий для каждого успешного действия и использует их для сравнения и отклонения дубликатов.

Проблема для нас заключалась в том, что нам требовались "более длительные, чем обычно", пользовательские сеансы (более 60 минут)и с более чем 1000 одновременно работающих пользователей мы утекли через этот механизм защиты всего через пару часов.

IBM рекомендовала полностью отключить кэш, используя следующую запись конфигурации portlet.xml: 

wps.multiple.action.execution = true

Это допускает двойное представление, которое может или не может нанести вред бизнес-функциональности.Однако наша внутренняя структура портала уже содержала механизм предотвращения двойной передачи, поэтому для нас это не было проблемой.

По нашему запросу IBM вернулась с патчем для этой проблемы, который позволяет настраивать кэш,то есть, давайте настроим количество результатов действий, которые вы сохраняете в кэше для каждого пользователя, и, таким образом, вы можете снова использовать механизм портала, с меньшими накладными расходами сеанса.Эти параметры конфигурации портала были следующими: 

wps.multiple.action.cache.bound.enabled = true
wps.multiple.action.cache.key.maxsize = 40
wps.multiple.action.cache.value.maxsize = 10

Вам нужно будет связаться с IBM по поводу этого патча, поскольку в данный момент его нет в выпущенном пакете исправлений.

1 голос
/ 18 января 2010

Может ли это быть кеш портлета? Вы можете активировать кэширование сервлетов и объявить длительное время истечения портлета. Цитата из techjournal :

Портлеты могут сообщать о своей способности кэшироваться в кэше фрагментов, устанавливая время их истечения в дескрипторе portlet.xml ( см. Пример дескриптора портлета ) 

<!-Expiration value is in seconds, -1 = no time limit, 0 = deactivated-->
    <expiration-cache>3600</expiration-cache> <!- 1 Hour cache -->

Чтобы использовать функции кэширования фрагментов, необходимо активировать кэширование сервлетов в разделе Web-контейнера административной консоли WebSphere Application Server (см. Пример дескриптора портлета). WebSphere Application Server также предоставляет корпоративное приложение для мониторинга кэша (CacheMonitor.ear), которое очень полезно для визуализации содержимого кэша фрагментов.

Обновление

У вас есть портлеты, которые устанавливают EXPIRATION_CACHE? Цитата:

Изменение локального кэша во время выполнения Для стандартных портлетов окно портлета может изменять время истечения во время выполнения, устанавливая свойство EXPIRATION_CACHE в RenderResponse следующим образом: 

RenderResponse.setProperty(
    PortletResponse.EXPIRATION_CACHE,
    (new Integer(3000)).toString() );

Обратите внимание, что для меня значение немного нелогично, -1 означает, что срок действия не истекает, 0 означает, что не кешируется.

0 голосов
/ 26 января 2010

На вашем сервере Websphere Portal установлен последний пакет исправлений?

http://www -01.ibm.com / поддержка / docview.wss? UID = swg24024380 & Rs = 0 и CS = UTF-8 & контекст = SSHRKX & dc = D420 & LOC = en_US & LANG = EN & куб.см = US

Также вас может заинтересовать следующее обсуждение

http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14427700&tstart=0

Обновление:

Просто бросать дротики в слепую.

  • "RES #" для меня звучит как ресурс.
  • Из трассировки стека форума, "DefaultActionResultManager.storeDocument" указывает, что хранит документ.

Следовательно, похоже, что ваши ресурсы (созданные страницы портала) кэшируются. Проверьте, есть ли какой-то параметр, который может ограничивать размер кэша ресурса.

Также в другом тесте установите срок действия кэша до 5 минут вместо часа.

...