[ 
https://issues.apache.org/jira/browse/OPENJPA-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Heath Thomann closed OPENJPA-2636.
----------------------------------
       Resolution: Fixed
    Fix Version/s: 2.4.2
                   2.2.3

> 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
>             Fix For: 2.2.3, 2.4.2
>
>
> 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)

Reply via email to