When a customer creates a plugin, for example a JDBCListener, there exists the possibility for the custom JDBCListener to retain a reference to a Classloader, which in turn will not allow the Classloader to be GC'd. For example, when the JDBCListener is part of a JEE application and the application is restarted, the JDBCListener class can be listed as as a leak suspect, as follows in this leak suspect stack:
75,675,296 (59.45%) [32] 67 class org/apache/openjpa/kernel/AbstractBrokerFactory 0x1027f7e8
As can be seen in this stack, my JDBCListener (class MyJDBCListener) is part of the leak suspect, with a retained Configurations class. When looking at the Configurations class, it can be seen that the Configurations class has a ConcurrentReferenceHashMap which contains a Classloader to Map, where the Map contains the JDBCListener class (MyJDBCListener). It is these two maps which causes the leak.
Thanks,
Heath
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4