We started with an out-of-box install of ColdFusion 11 x64 on Windows 2008 R2. As sites were added to the server, we noticed a memory leak started to become apparent. There was plenty of information about this error being a bug in the older JRE, so we upgraded staging, and eventually production, to jre1.8.0_45. The memory leak still persists - after about 3 weeks, the 4GB heap fills up and the server starts to slowdown, so we restart ColdFusion. If we let it continue to run, ColdFusion starts to throw out-of-memory errors.
From the last time when the heap utilization was about 50% after 7 days:
The class "java.io.DeleteOnExitHook", loaded by "<system class loader>", occupies 1,165,311,936 (51.15%) bytes. The memory is accumulated in one instance of "java.util.LinkedHashMap" loaded by "<system class loader>".
Does anyone have an idea of where to look from this point? There are no recent discussions about this memory leak in my searching.
The exact problem: Bug ID: JDK-6664633 DeleteOnExitHook leaks memory (with fix)
Current server update level:
Tomcat Version 126.96.36.199
Operating System Windows Server 2008 R2
OS Version 6.1
Update Level C:/ColdFusion11/cfusion/lib/updates/chf11000005.jar
Adobe Driver Version 5.1.3 (Build 000094)
Java Version 1.8.0_45
We have 58 SQL Server datasources, and 2 MS Access datasources running on this server.
No website files reference DeleteOnExitHook directly.
ColdFusion has DeleteOnExitHook in the following files:
The JRE has DeleteOnExitHook in the following files:
The DeleteOnExitHook resources all point to \Temp\ddtb377039557646079978.tmp or other various files that start with ddtb and have .tmp extensions. I believe these are related to a leak in the JDBC driver. Happens on all of our CF11 servers. Our CF10 servers appear to have a resource leak also, but I am not yet able to create heap dumps from the CF10 environments due to how they are configured. Our CF10 environments have far fewer sites though, so this problem isn't affecting those servers nearly as much.
I also have this problem - submitted a bug report to adobe. In the mean time, I found some code here that I was able to rework:
to clean up the memory on a scheduled task.
I have switched to jTDC...
But if you can't... you can try DDTEK.includeFinalizers=false