Дамп утечки соединения в WildFly

Question

Я пытаюсь сбросить утечку соединений, управляемых источником данных MySQL в WildFly 10.1, но я не могу найти файл утечки или дамп утечки.

Почему leaks.txt файл не генерируется? А также, где я должен искать файл?

Процедура

Я зарегистрировал пул соединений утечки в standalone.bat файл:

"JAVA_OPTS=%JAVA_OPTS% -Dironjacamar.mcp=org.jboss.jca.core.connectionmanager.pool.mcp.LeakDumperManagedConnectionPool -Dironjacamar.leaklog=leaks.txt"

Я могу подтвердить, что свойства устанавливаются в WildFly, так как показывает в журнале:

JAVA_OPTS: "-Dprogram.name=standalone.bat -Xms64M -Xmx512M -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Dironjacamar.mcp=org.jboss.jca.core.connectionmanager.pool.mcp.LeakDumperManagedConnectionPool -Dironjacamar.leaklog=leaks.txt"

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

[standalone@localhost:9990 /] /subsystem=datasources/data-source=mysql-ds:flush-all-connection-in-pool
{"outcome" => "success"}

Но я не могу найти leaks.txt файл в любом месте.

Я использую эту статью, а также документацию по утечке IronJacamar в качестве ссылки.

Пул детекторов утечки настраивается с помощью системного свойства ironjacamar.mcp со значением

org.jboss.jca.core.connectionmanager.pool.mcp.LeakDumperManagedConnectionPool

Эта конфигурация применяется ко всем пулам соединений, используемым IronJacamar.

Системное свойство ironjacamar.leaklog можно использовать для удаления утечек в специальный файл, отдельный от настройки ведения журнала.

Пример

-Dironjacamar.mcp=org.jboss.jca.core.connectionmanager.pool.mcp.LeakDumperManagedConnectionPool -Dironjacamar.leaklog=leaks.txt

Обновления

Тема 969369 создана на форуме JBoss, поэтому они также могут помочь с этим.

Об ошибке сообщили JBJCA-1360.

Answer 1

Тема 969369 создана на форуме JBoss, поэтому они также могут помочь с этим.

Временное решение

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

Обходной путь для этого позволяет debug а также error режимы true для подсистемы JCA (кажется, перезапуск сервера не требуется).

/subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=debug, value=true)
/subsystem=jca/cached-connection-manager=cached-connection-manager:write-attribute(name=error, value=true)

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