Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > Java EE (J2EE) и Spring > Утечка памяти в jgroups при рестарте сервера?

Автор: lamao 1.11.2012, 13:19

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

Код


The leaking classloader is being held
in org.jgroups.util.Util$1
in groups of java.lang.ThreadGroup

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

Код


private static ThreadGroup GLOBAL_GROUP=new ThreadGroup("JGroups") {
        public void uncaughtException(Thread t, Throwable e) {
            LogFactory.getLog("org.jgroups").error("uncaught exception in " + t + " (thread group=" + GLOBAL_GROUP + " )", e);
        }
    };

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

Код


public class JGroupsCleanerListener implements ServletContextListener {

    private final static Logger logger = LoggerFactory.getLogger(JGroupsCleanerListener.class);
    
    @Override
    public void contextInitialized(ServletContextEvent sce) {
        // nop        
    }

    @Override
    public void contextDestroyed(ServletContextEvent sce) {
        try {
            Field field = Util.class.getDeclaredField("GLOBAL_GROUP");
            field.setAccessible(true);
            field.set(null, null);
            logger.info("Util.getGlobalThreadGroup() = {}", Util.getGlobalThreadGroup());
            
            ThreadGroup rootGroup = getRootThreadGroup();
            ThreadGroup groups[] = new ThreadGroup[rootGroup.activeGroupCount()]; 
            rootGroup.enumerate(groups);
            
            for (int i = 0; i < groups.length; i++) {
                if (groups[i].getName().equals("JGroups")) {
                    final ThreadGroup jgroupsGroup = groups[i];
                    jgroupsGroup.interrupt();
                    
                    Thread thread = new Thread() {
                      @Override
                      public void run() {
                        while (jgroupsGroup.activeCount() > 0) {                        
                        }
                        jgroupsGroup.destroy();
                      }  
                    };
                    thread.start();
                }
            }
        } catch (SecurityException e) {
            logger.error(e.getMessage(), e);
        } catch (NoSuchFieldException e) {
            logger.error(e.getMessage(), e);
        } catch (IllegalArgumentException e) {
            logger.error(e.getMessage(), e);
        } catch (IllegalAccessException e) {
            logger.error(e.getMessage(), e);
        }        
    }
    
    private ThreadGroup getRootThreadGroup() {
        ThreadGroup currentGroup = Thread.currentThread().getThreadGroup();
        
        while (currentGroup.getParent() != null) {
            currentGroup = currentGroup.getParent();
        }
        
        return currentGroup;
    }
    
}

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

Код


The leaking classloader is being held
in org.springframework.security.access.method.AbstractMethodSecurityMetadataSource

The leaking classloader is being held
in org.springframework.security.web.access.expression.WebSecurityExpressionRoot

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

Код


01.11.2012 11:49:19 org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
SEVERE: A web application appears to have started a thread named [Resource Destroyer in BasicResourcePool.close()] but has failed to stop it. This is very likely to create a memory leak.

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

Автор: jk1 1.11.2012, 16:14

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

Автор: lamao 2.11.2012, 11:24

Нашел соответсвующий баг в джире jgroups https://issues.jboss.org/browse/JGRP-1410. Хех, надо было сразу туда лезть. Правда фикс, который они предлагают не работает и по-моему работать и не должен. В моем варианте (я его еще несколько модифицировал) остается 30 потоков, которые видно просто игнорируют метод interrupt().

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

Код


public void contextDestroyed(ServletContextEvent sce) {
        try {
            ThreadGroup globalThreadGroup = Util.getGlobalThreadGroup();
            Field field = Util.class.getDeclaredField("GLOBAL_GROUP");
            field.setAccessible(true);
            field.set(null, null);
            logger.info("Util.getGlobalThreadGroup() = {}", Util.getGlobalThreadGroup());
            
            if (!globalThreadGroup.isDestroyed()) {

                if (globalThreadGroup.activeCount() > 0) {
                    logger.warn("Active threads still running in JGroups global thread group.  Waiting 2 seconds.");
                    try {
                        Thread.sleep(2000);
                    } catch (InterruptedException exception) {
                        Thread.currentThread().interrupt();
                    }
                
                }

                while (globalThreadGroup.activeCount() > 0) {
                    logger.warn("{} active threads still running in JGroups global " +
                         "thread group.  Trying to interrupt and waiting for 500 ms",
                         globalThreadGroup.activeCount());
                    globalThreadGroup.interrupt();
                    Thread.sleep(500);
                }
                globalThreadGroup.destroy();
                logger.info("JGroups global thread group is destroyed.");
            }
        } catch (Exception exception) {
            logger.error("Error while destroying JGroups global thread group.", exception);
        }        
    }

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

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

Автор: lamao 6.11.2012, 17:38

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

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

Это около 6000 при каждом редеплое smile

Автор: COVD 8.11.2012, 08:17

Цитата

В приложении одним из артефактов используется jgroups

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

Автор: lamao 9.11.2012, 13:25

Цитата(COVD @ 8.11.2012, 08:17)

Цитата

В приложении одним из артефактов используется jgroups

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

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

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

Автор: COVD 9.11.2012, 14:44

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

p.s.

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

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

Автор: lamao 9.11.2012, 17:06

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

Автор: COVD 9.11.2012, 19:12

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

Автор: lamao 13.11.2012, 13:16

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