Утечка памяти в JBoss

Question

У меня очень странное поведение в JBoss, и я бы хотел воспользоваться Коллективной Мудростью ТАКОЙ Толпы.

Мы используем JBoss (я думаю, 4.0.4) для обслуживания вызовов SOAP. На самом деле, он используется как прославленный RPC-сервер, не более того. У нас заканчивается память, когда более 20 клиентов отправляют свои запросы одновременно. Запросы состоят из входящего довольно небольшого запроса (собственно SOAP) и возвращаемого результирующего пакета, который, по сути, представляет собой одну длинную строку SOAP (а содержимое строки - XML). Да, я понимаю, что это неоптимально. Не спрашивай.

Я проследил утечку до экземпляра org.jboss.axis.message.SAX2EventRecorder, который содержит 4 миллиона объектов (строки и целые числа). Теперь даже самый длинный ответ не несет 4 МБ данных. Все запросы меньше 40К. Там что-то подозрительно, но я не могу найти никакой документации в Интернете.

Может кто-нибудь сказать мне, для чего используется рекордер? И как мне от этого избавиться? Или может быть настроить его, чтобы быть менее требовательным к памяти? Любая помощь приветствуется.

---

Обновление: чтобы уточнить - я сделал дамп памяти, и дамп показывает массив или более 4 000 000 объектов, строк и целых чисел. Массив принадлежит org.jboss.axis.message.SAX2EventRecorder, который, в свою очередь, принадлежит этим парням:

org.jboss.axis.message.SOAPEnvelopeAxisImpl@0x19c31fd8 (141 байт): полевой регистратор org.jboss.axis.message.RPCParamElementImpl@0x19c32260 (123 байта): полевой регистратор org.jboss.axis.message.SOAPBodyAxisImpl@0x19c32160 (121 байт): полевой регистратор org.jboss.axis.message.RPCElement@0x19c321e0 (124 байта): полевой регистратор org.jboss.axis.encoding.DeserializationContextImpl@0x19c332f0 (67 байт): полевой регистратор org.jboss.axis.message.SAX2EventRecorder$objArrayVector@0x19c33398 (24 байта): введите это поле $ 0

Структуры данных нашего собственного приложения раздуты, но не до такой степени.

Еще одно обновление: полномочия, которые были найдены как «решения, которые могут быть использованы»: мы переключаемся на 64-битную память. Ура.

Answer 1

Запустить с JVM arg -XX: -HeapDumpOnOutOfMemoryError. Это даст вам кучу дампов, когда у вас закончится память. Затем вы можете проанализировать дамп кучи с помощью инструмента jhat (он поставляется вместе с JDK). Кроме того, вы можете использовать инструмент jconsole (который также входит в комплект JDK) для запроса дампа кучи в любое время с помощью MBeans для управления памятью.

Он расскажет вам, что на самом деле содержат эти 4 миллиона объектов, что может дать вам представление о том, почему программное обеспечение не высвобождает эту память.

EDIT:

Кажется, вы не единственный с этой проблемой. В Axis

зарегистрировано 2 сообщения об ошибках.

AXIS-2698

AXIS-2749

См. Также AXIS-1771 , в нем содержится некоторая интересная информация, касающаяся десериализации и способов обеспечения ее воздействия. Какую версию Axis вы используете?

Answer 2

Если вы можете, запустите приложение под Java 6. Последняя версия включает VisualVM для профилирования. Должно быть в состоянии показать рост памяти. Вы можете подключиться к виртуальной машине Java 5, но она не показывает столько же.