2015-09-23 3 views
0

Мое приложение использует как RMI, так и JDBC для связи с удаленной системой и базой данных. В то время как проблемы с базой данных были решены, выясняется, что RMI вызывает некоторую форму утечки памяти, обнаруженную Tomcat 6 (я также пробовал это с Tomcat 7, и у нас такая же проблема).RMI/Tomcat 6 Утечка памяти

В основном, когда мы запускаем приложение и пользователь вводит информацию на веб-страницу, вызов RMI производится в бэкэнд-системе. Если мы остановимся/запустим или перезапустим приложение, Tomcat Manager теперь сможет обнаруживать утечку памяти. Если мы запустим приложение и НЕ выполняем вызов RMI, мы можем запустить/остановить & перезапустить приложение в течение всего дня без проблем.

Кто-нибудь знает, что нужно сделать, чтобы предотвратить вызовы RMI из-за утечек памяти в WebappClassLoader при перезагрузке или остановке/запуске, пока веб-сервер все еще работает?

+0

что сообщение от tomcat? Это о ThreadLocal? – ZhongYu

+0

Нет, это просто - в журналах нет сообщения об ошибке. НО, Tomcat Manager утверждает, что утечка была обнаружена, если я нажимаю кнопку «Найти утечки» после выполнения чего-то в приложении, которое использует вызов RMI, а затем перезагружает/останавливает приложение с помощью Менеджера. Я вижу в jvisualvm, что действительно создается новый WebappClassLoader (контекст). – kvgeorge1

ответ

0

Мое приложение использует как RMI, так и JDBC для связи с удаленной системой и базой данных. В то время как проблемы с базой данных были устранены, выясняется, что RMI вызывает определенную форму утечки памяти, обнаруженную Tomcat 6 ... Кто-нибудь знает, что необходимо сделать, чтобы предотвратить вызовы RMI из-за утечек памяти в WebappClassLoader после перезагрузки или остановить/запустить, пока веб-сервер все еще работает?

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

+0

Когда я останавливаю/запускаю или перезагружаю приложение, Tomcat обнаруживает утечку памяти, если после этого я проверю с помощью Менеджера. Я профилировал JVM с помощью jvisualvm, и виновником, похоже, является sun.rmi.transport.DGCClient, который находится на вершине GC Root. Вы запускаете/останавливаете или перезагружаете приложение с помощью веб-сервера, или вы останавливаете tomcat после развертывания? – kvgeorge1

+0

Я могу перезагрузить его один или два раза с помощью Tomcat, после чего мне нужно перезагрузить Tomcat. Но это относится и к Тому, который также относится к RMI. Здесь вам нужно будет предоставить правильные данные. Какая утечка памяти? Каковы ваши доказательства того, что RMI участвует? Как выглядит ваш код RMI? – EJP

+0

Я не имею права раскрывать код как таковой, но вот почему я говорю, что у нас есть утечка памяти. Tomcat Manager утверждает, что утечка была обнаружена, если я нажимаю кнопку «Найти утечки» после выполнения чего-то в приложении, которое использует вызов RMI, а затем перезагружает/останавливает приложение с помощью диспетчера. Я вижу в jvisualvm, что действительно создается новый WebappClassLoader (контекст). – kvgeorge1

0

DGCClient не очистил все ресурсы, связанные с RMI, и ему нужно было дождаться таймаута, чтобы стрелять. Поскольку контейнер пытался остановиться, но ресурсы RMI зависали, это вызвало утечку памяти в соответствии с Tomcat Manager, которая сама очистила и исправила условие утечки памяти после того, как ресурсы RMI были собраны DGC.

Смежные вопросы