I am trying to dump leaked connections managed by a MySQL Data Source in WildFly 10.1, but I am not able to find the leak file or the leak dump.
Why is the leaks.txt
file not being generated? And also, where should I look for the file?
Procedure
I registered the leak connection pool in the standalone.bat
file:
"JAVA_OPTS=%JAVA_OPTS% -Dironjacamar.mcp=org.jboss.jca.core.connectionmanager.pool.mcp.LeakDumperManagedConnectionPool -Dironjacamar.leaklog=leaks.txt"
I can confirm that properties are being set in WildFly since shows in the log:
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"
After it, I leak some connections in my mock application in order to generate data. Then I run the CLI command flushing all connections getting a positive response:
[standalone@localhost:9990 /] /subsystem=datasources/data-source=mysql-ds:flush-all-connection-in-pool
{"outcome" => "success"}
But I can't find the leaks.txt
file anywhere.
I am using this article and also IronJacamar leak documentation as reference.
The leak detector pool is configured using the ironjacamar.mcp system property with a value of
org.jboss.jca.core.connectionmanager.pool.mcp.LeakDumperManagedConnectionPool
This configuration applies to all connection pools used by IronJacamar.
The system property ironjacamar.leaklog can be used to have the leaks dumped out into a special file separate from the logging setup.
An example
-Dironjacamar.mcp=org.jboss.jca.core.connectionmanager.pool.mcp.LeakDumperManagedConnectionPool -Dironjacamar.leaklog=leaks.txt
Updates
Thread 969369 created in JBoss forum so they can help with it as well.
Bug reported JBJCA-1360.
Thread 969369 created in JBoss forum so they can help with it as well.
Workaround
There is an alternative approach to log leak connections, however I think it shouldn't apply as a final answer to this question.
The workaround for this is enabling
debug
anderror
modes to true for JCA Subsystem (It seems that restarting the server is not needed).You can check the logs as the server will dump exceptions pointing out the stacktrace that helps you find the leaks. It is not as clean, but it helped us find where the problem was in our code.