1 Reply Latest reply on Oct 12, 2015 1:59 AM by pmm

    Does xnio-file-watcher bring classloader leak?

    xkylex
    xkylex Oct 11, 2015 9:10 AM

      Hello,

       

      I'm working on fixing the issue "java.lang.OutOfMemoryError: Metaspace" in the time of redeploy where running an web application (Apache Roller, Java EE weblogger software: https://roller.apache.org) on WildFly 10.0.0.CR2.

       

      I have fixed some existing issues such as ThreadLocal and Google Guice finalizer issue, and now the app running fine on Tomcat8 without OOME if I do any times of redeploy, but it still produces OOME on WildFly.

       

      Then, I've found a ServletContextListener called "Classloader leak prevention library" (https://github.com/mjiderhamn/classloader-leak-prevention) fixes the issue that prevents classloader leak for my app that deployed on WildFly. I can do any times of redeploy when the app is deployed with that ServletContextListener.

       

      The "Classloader leak prevention library" produces following logs (in https://github.com/mjiderhamn/classloader-leak-prevention/blob/master/src/main/java/se/jiderhamn/classloader/leak/prevention/ClassLoaderLeakPreventor.java#L1373-L1376):

       

      ClassLoaderLeakPreventor: private java.util.Map javax.faces.component.UIComponentBase.descriptors is not static

      ClassLoaderLeakPreventor: Unable to unregister NotificationEmitterSupport listeners, because details could not be found using reflection

      ClassLoaderLeakPreventor: Internal registry of java.beans.PropertyEditorManager not found

      ClassLoaderLeakPreventor: Thread 'Thread[xnio-file-watcher[Watcher for /Users/kyle/src/roller/app/target/exploded/roller.war/]-0,5,main]' of type java.lang.Thread running in web app; waiting 5000

      ClassLoaderLeakPreventor: Thread 'Thread[xnio-file-watcher[Watcher for /Users/kyle/src/roller/app/target/exploded/roller.war/]-0,5,main]' of type java.lang.Thread still running in web app; changing context classloader to system classloader

      ClassLoaderLeakPreventor: Shutting down java.util.concurrent.ThreadPoolExecutor running within the classloader.

      ClassLoaderLeakPreventor: Thread 'Thread[Thread-235,5,main]' of type java.lang.Thread running in web app; waiting 5000

       

      According to the log, the thread named xnio-file-watcher is doing something wrong, and forced to set its context classloader to system classloader.

       

      So here's my question: Does xnio-file-watcher prevents my webapp to be undeployed successfully? I'm newbie to investigate the "OOME: Metaspace" issue, any other pointers or advices would be appreciated. Thanks.

      • 345 Views
      • Tags:
        • 1. Re: Does xnio-file-watcher bring classloader leak?
          pmm
          pmm Oct 12, 2015 1:59 AM (in response to xkylex)

          I believe officially there are no known classloader leaks within WildFly. Having that said there are known Java SE offenders which AFAIK WildFly does not work around. However these would leak your application only once. Looking at the library you posted it seems many if not all things can be avoided by following Java EE best practices like

          • not deploying the database driver with your application
          • not deploying Java EE implementations with your application
          • not spawning custom threads

          to be sure you'd have to undeploy your application and look at a heap dump.

          1 of 1 people found this helpful
            • Actions