Uploaded image for project: 'WildFly'
  1. WildFly
  2. WFLY-3365

ClassLoader leak in org.jboss.el.cache.FactoryFinderCache

XMLWordPrintable

    • Hide

      The attached application demonstrates the issue. Deploy, undeploy, heap dump. The application contains a ServletContextListener that creates a static reference to a "LeakMarker" object to simplify finding the leaked ModuleClassLoader.

      org.xnio.nio.WorkerThread @ 0x7b90fa3b0  XNIO-1 I/O-2 Thread                                                          
'- contextClassLoader org.jboss.modules.ModuleClassLoader @ 0x7b8224be0                                               
   '- module org.jboss.modules.Module @ 0x7b8224b40                                                                   
      '- moduleLoader org.jboss.modules.LocalModuleLoader @ 0x7b82241e0                                               
         '- moduleMap org.jboss.modules.UnlockedReadHashMap @ 0x7b8224220                                             
            '- table java.util.concurrent.atomic.AtomicReferenceArray @ 0x7b8224270                                   
               '- array java.lang.Object[512] @ 0x7b8224280                                                           
                  '- [345] org.jboss.modules.UnlockedReadHashMap$Item[1] @ 0x7b8010000                                
                     '- [0] org.jboss.modules.UnlockedReadHashMap$Item @ 0x7b8010018                                  
                        '- value org.jboss.modules.ModuleLoader$FutureModule @ 0x7b8010030                            
                           '- module org.jboss.modules.Module @ 0x7b84c1360                                           
                              '- moduleClassLoader org.jboss.modules.ModuleClassLoader @ 0x7b84c0f98                  
                                 '- classes java.util.Vector @ 0x7b84c1078                                            
                                    '- elementData java.lang.Object[20] @ 0x7b9597c20                                 
                                       '- [10] class org.jboss.el.cache.FactoryFinderCache @ 0x7b9597d48              
                                          '- CLASS_CACHE java.util.concurrent.ConcurrentHashMap @ 0x7b9597db0         
                                             '- table java.util.concurrent.ConcurrentHashMap$Node[16] @ 0x7b9597df0   
                                                '- [5] java.util.concurrent.ConcurrentHashMap$Node @ 0x7bf5b6b40      
                                                   '- key org.jboss.el.cache.FactoryFinderCache$CacheKey @ 0x7bf5b6b60
                                                      '- loader org.jboss.modules.ModuleClassLoader @ 0x7bf380c78     
                                                         '- classes java.util.Vector @ 0x7bf380df8                    
                                                            '- elementData java.lang.Object[10] @ 0x7bf380e18         
                                                               '- [0] class leak.LeakListener @ 0x7bf388a88           
                                                                  '- LEAK_MARKER leak.LeakMarker @ 0x7bf388af0
      Show
      The attached application demonstrates the issue. Deploy, undeploy, heap dump. The application contains a ServletContextListener that creates a static reference to a "LeakMarker" object to simplify finding the leaked ModuleClassLoader. org.xnio.nio.WorkerThread @ 0x7b90fa3b0 XNIO-1 I/O-2 Thread '- contextClassLoader org.jboss.modules.ModuleClassLoader @ 0x7b8224be0 '- module org.jboss.modules.Module @ 0x7b8224b40 '- moduleLoader org.jboss.modules.LocalModuleLoader @ 0x7b82241e0 '- moduleMap org.jboss.modules.UnlockedReadHashMap @ 0x7b8224220 '- table java.util.concurrent.atomic.AtomicReferenceArray @ 0x7b8224270 '- array java.lang. Object [512] @ 0x7b8224280 '- [345] org.jboss.modules.UnlockedReadHashMap$Item[1] @ 0x7b8010000 '- [0] org.jboss.modules.UnlockedReadHashMap$Item @ 0x7b8010018 '- value org.jboss.modules.ModuleLoader$FutureModule @ 0x7b8010030 '- module org.jboss.modules.Module @ 0x7b84c1360 '- moduleClassLoader org.jboss.modules.ModuleClassLoader @ 0x7b84c0f98 '- classes java.util.Vector @ 0x7b84c1078 '- elementData java.lang. Object [20] @ 0x7b9597c20 '- [10] class org.jboss.el.cache.FactoryFinderCache @ 0x7b9597d48 '- CLASS_CACHE java.util.concurrent.ConcurrentHashMap @ 0x7b9597db0 '- table java.util.concurrent.ConcurrentHashMap$Node[16] @ 0x7b9597df0 '- [5] java.util.concurrent.ConcurrentHashMap$Node @ 0x7bf5b6b40 '- key org.jboss.el.cache.FactoryFinderCache$CacheKey @ 0x7bf5b6b60 '- loader org.jboss.modules.ModuleClassLoader @ 0x7bf380c78 '- classes java.util.Vector @ 0x7bf380df8 '- elementData java.lang. Object [10] @ 0x7bf380e18 '- [0] class leak.LeakListener @ 0x7bf388a88 '- LEAK_MARKER leak.LeakMarker @ 0x7bf388af0

      After deploy/undeploy of a webapp that uses org.jboss.el, a reference to the webapp classloader remains in FactoryFinderCache.

      I currently work around this by calling FactoryFinderCache.clearClassLoader in a ServletContextListener. Uncommenting line 26 in LeakListener makes the reference go away on undeploy.

              tomazcerar Tomaž Cerar (Inactive)
              bjorn_jira Björn Sköld (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: