You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2016/04/01 17:03:25 UTC
[jira] [Commented] (OPENJPA-2636) Custom plugins (e.g.
JDBCListener, DBDictionary) can cause Classloader leaks.
[ https://issues.apache.org/jira/browse/OPENJPA-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15221811#comment-15221811 ]
ASF subversion and git services commented on OPENJPA-2636:
----------------------------------------------------------
Commit 1737410 from [~jpaheath] in branch 'openjpa/branches/2.2.x'
[ https://svn.apache.org/r1737410 ]
OPENJPA-2636: Updated a Map in Configurations to avoid a ClassLoader leak.
> Custom plugins (e.g. JDBCListener, DBDictionary) can cause Classloader leaks.
> -----------------------------------------------------------------------------
>
> Key: OPENJPA-2636
> URL: https://issues.apache.org/jira/browse/OPENJPA-2636
> Project: OpenJPA
> Issue Type: Bug
> Components: jdbc
> Affects Versions: 2.2.3, 2.4.2
> Reporter: Heath Thomann
> Assignee: Heath Thomann
> Priority: Minor
>
> 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
> |- 75,637,832 (59.42%) [32] 40 class org/apache/openjpa/lib/conf/Configurations 0xf370b48
> |- 75,637,552 (59.42%) [64] 2 org/apache/openjpa/lib/util/concurrent/ConcurrentReferenceHashMap 0x1110fa40
> |- 75,637,464 (59.42%) [64] 3 array of org/apache/openjpa/lib/util/concurrent/ConcurrentReferenceHashMap$Entry 0x11115620
> |- 75,514,544 (59.32%) [48] 4 org/apache/openjpa/lib/util/concurrent/ConcurrentReferenceHashMap$WeakEntry 0x1111edb0
> |- 75,514,496 (59.32%) [48] 1 java/util/concurrent/ConcurrentHashMap 0x111f47b8
> |- 75,514,448 (59.32%) [80] 16 array of java/util/concurrent/ConcurrentHashMap$Segment 0x111f47e8
> |- 75,505,976 (59.32%) [32] 2 java/util/concurrent/ConcurrentHashMap$Segment 0x111f48d0
> |- 75,505,912 (59.32%) [24] 1 array of java/util/concurrent/ConcurrentHashMap$HashEntry 0x110d8f08
> |- 75,505,888 (59.32%) [24] 2 java/util/concurrent/ConcurrentHashMap$HashEntry 0x110d8f18
> |- 75,505,752 (59.32%) [32] 18 class listener/MyJDBCListener 0x10296078
> |- 75,505,600 (59.31%) [48] 1 java/util/HashMap 0x11113f88
> |- 75,505,552 (59.31%) [65,552] 6,411 array of java/util/HashMap$Entry 0x1401ed10
> 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
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)