0

Please find below the dominator tree when analyzing the heap dump after an OOM error occured. 87% of the memory is consumed by a huge list of LinkedHashMap which is referencing the JTDS temp files. I do not understand why so many temp files are being created and they aren't being deleted due to possible references of the LinkedHashMap blocking garbage collection. But why can this happen? Is this a connection pooling related issue? Correct me if I am wrong regarding the analysis.

I am using the following version of libraries :

java 1.8 v291
Tomcat v9.0.54
Spring v4.1.6
Hibernate v4.0
JTDS v1.2.2
C3P0 v0.9.1.2
JNDI v1.2.1

enter image description here

arunken
  • 415
  • 3
  • 15

1 Answers1

0

According to https://sourceforge.net/p/jtds/bugs/562/ this was fixed in 2009?

See also e.g.: https://github.com/milesibastos/jTDS/blob/master/src/main/net/sourceforge/jtds/util/BlobBuffer.java

Where this code is commented out to avoid this leak:

// blobFile.deleteOnExit(); memory leak, see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6664633

You may also be able to tweak the size limit: https://answers.axonivy.com/questions/2007/how-to-improve-performance-of-mssql-system-database-with-jtds-driver-many-temporary-files or patch jTDS but you may also want to consider switching to the MSSQL Java driver: differences between ms sql microsoft's jdbc drivers and jTDS's driver

JohannesB
  • 2,214
  • 1
  • 11
  • 18