Сервер - томкат. В приложении одним из артефактов используется jgroups (вроде 2.10). С добавлением этого артефакта стал намного чаще падать сервер при редеплое и перезапуске. Для установлении причины был использован Plumbr. Если не учитывать проблеммы самого томката, то единственной причиной есть 



А именно кусок кода в org.jgroups.util.Util


Для решение проблеммы был написан слушатель JGroupsCleanerListener, который, во-первых, зануляет статическую переменную, во-вторых, убивает все потоки в группе JGroups и удаляет ее.


Но все равно выдает, что есть утечка памяти. Теперь уже в таких местах


И раз было еще что-то с таймерами связано. Кроме того в логах появляется запись. Не знаю, связана ли она с изменениями, или была и раньше.


Я в механизме работы потоков в джаве разбираюсь плохо. Поэтому два вопроса:
1) Правильно ли я пофиксил проблемму?
2) Если нет, то как правильно?

А профайлер подтверждает, что память течет?
Просто у plumbr бывают ложные срабатывания, чего и сами создатели не отрицают

Нашел соответсвующий баг в джире jgroups globalThreadGroup not destroyed creates a classloader memory leak . Хех, надо было сразу туда лезть. Правда фикс, который они предлагают не работает и по-моему работать и не должен. В моем варианте (я его еще несколько модифицировал) остается 30 потоков, которые видно просто игнорируют метод interrupt().

Вот мой последний код. Он зацикливается в while (globalThreadGroup.activeCount() > 0) {


Используется это либа как зависимость в артефакте ehcache-replication (у нас). Так глядя на помник в мавен репозитории, вижу, что в последней версии (1.7) они поменяли версию зависимости на 3.1, где как общеают разработчики этот баг пофикшен.

Добавлено через 7 минут и 2 секунды
И да, профайлер подтверждает утечку. Использую дефолтный Java VisualVM. Количество потоков при рестарте не увеличивается, heap, кол-во классов и PermGen увеличивается существенно.

Это сообщение отредактировал(а) lamao - 2.11.2012, 11:28

В общем ребята из комьюнити обещали пофиксить в версии 3.3 (так в fixVersion). Посмотрим как скоро это будет.

А корневая причина бага в том, что то ли группа потоков, то ли поток содержит ссылку на класслоадер. Плюс группа потоков прикрепляется как дочерняя к системной группе. И вот получается если ее не убить (а это нельзя сделать не закончив те 30 потоков, которые не убиваются) то будет висячий обьект (с точки зрения нашего приложения) который содержит ссылку на класслоадер приложения, который содержит ссылку на все классы приложения...   Это около 6000 при каждом редеплое   

А нельзя сделать один общий jgroups, который стартует с Томкатом и выключается только с ним же? И забыть.

Нет нельзя. На одном сервере запускается два приложения, которые общаются между собой (через сокеты в конце концов вроде). Нужно поднимать для каждого свой. 
Короче, записал я это все в их джиру, обещают в 3.3 все же пофиксить.

Добавлено через 25 секунд
--------------------

Почему нельзя. Есть же контекст сервера, который доступен приложениям, если я не путаю. Я примерно так использую Hazelcast, который тоже использует мультикастинг, а возможно и использует jgroups для реализации этого. И jar Hazelcast'a в единственном экземпляре лежит у меня в папке lib Томката, а все веб-приложения имеют доступ к общей памяти, которая еще и распределенная, потому что доступна другому Томкату и его приложениям тоже.

p.s.

Когда приложения стартуют-останавливаются, они должно входить и выходить из группы. Но обьект группы может быть статический, один на сервер. Он инициализируется один раз при старте сервера. 

Не знаю, как сейчас, но jgroups была довольно низкоуровневая библиотека. Я перестал с ней разбираться, когда обнаружил Hazelcast, который упрощенно мне представлялся как jgroups + коллекции. И смысла не стало строить свое вокруг jgroups. Для решения задач авторизации доступа этого было вполне достаточно.

Это сообщение отредактировал(а) COVD - 9.11.2012, 16:01

Хм... Не знаю. Возможно и можно будет использовать общую библиотеку на уровне сервера. Мы jgroups тоже используем не напрямую. Его использует ehcache для репликации при распределенном кэше. Вот надо или с jgroups что-то решить, либо использовать другой транспорт. 

Тогда, возможно, ehcache имеет смысл вынести из приложений на уровень сервера. Веб приложения должны хорошо делать свою основную работу - обрабатывать http. От остального их лучше избавлять.

Это сообщение отредактировал(а) COVD - 9.11.2012, 19:16

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