Application classloader leaked by IIOP WorkCacheManager cache

Environment

• JBoss Enterprise Application Platform (EAP) 7.2.0 and earlier

Issue

• We see a Metaspace OOME after application redeploys. The heap dump shows our application classloader is still contained in a org.wildfly.iiop.openjdk.rmi.WorkCacheManager cache

com.sun.corba.se.impl.transport.SelectorImpl @ 0xc12234b8  SelectorThread Thread
'- contextClassLoader org.jboss.modules.ModuleClassLoader @ 0xc075bea0
   '- classes java.util.Vector @ 0xc075c4a8
      '- elementData java.lang.Object[160] @ 0xc1afb200  
         '- [58] class org.wildfly.iiop.openjdk.rmi.ValueAnalysis @ 0xc180e4b0  |
            '- cache org.wildfly.iiop.openjdk.rmi.WorkCacheManager @ 0xc180e520
               |- classesByLoader java.util.HashMap @ 0xc180e730
               |  '- table java.util.HashMap$Node[16] @ 0xc1ba2ff8 
               |     |- [14] java.util.HashMap$Node @ 0xc37b01e0 
               |     |  '- key org.jboss.modules.ModuleClassLoader @ 0xc3677958

Resolution

• Upgrade to 7.2.2+

Root Cause

• Content from issues.jboss.org is not included.JBEAP-16465
• Content from issues.jboss.org is not included.WFLY-11784
• This was previously a weak map, but we switched to strong caching with explicit clean up on undeploy. It looks like that clean up is missed in some case.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.