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

ManagedExecutorService persists contextClassLoader reference to cause app classloader leaks

    XMLWordPrintable

Details

    Description

      managed executor:

      <managed-executor-services>
    <managed-executor-service name="default" jndi-name="java:jboss/ee/concurrency/executor/default" context-service="default" hung-task-threshold="60000" keepalive-time="5000"/>
</managed-executor-services>

      With each undeploy, the application classloader is leaked and not released because contextClassLoader references persisted on the executor threads:

      Class Name                                                                                                                                          | Ref. Objects | Shallow Heap | Ref. Shallow Heap | Retained Heap
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
org.jboss.as.ee.concurrent.service.ElytronManagedThreadFactory$ElytronManagedThread @ 0xc3677570  EE-ManagedExecutorService-default-Thread-13 Thread|            1 |          160 |                88 |         1,344
'- contextClassLoader org.jboss.modules.ModuleClassLoader @ 0xc32b9d98                                                                              |            1 |           88 |                88 |       366,800
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

      Tracing with byteman, what's strange is that it sets the app classloader on setup:

      Thread.setContextClassLoader: Thread[EE-ManagedExecutorService-default-Thread-16,5,ServerService ThreadGroup] ModuleClassLoader for Module "deployment.services-1.0.4-rc1.war" from Service Module Loader
java.lang.Thread.setContextClassLoader(Thread.java:1477)
org.wildfly.security.manager.WildFlySecurityManager.setCurrentContextClassLoaderPrivileged(WildFlySecurityManager.java:1272)
org.jboss.as.ee.concurrent.handle.ClassLoaderContextHandleFactory$ClassLoaderSetupContextHandle.setup(ClassLoaderContextHandleFactory.java:83)
org.jboss.as.ee.concurrent.ConcurrentContext$ChainedSetupContextHandle.setup(ConcurrentContext.java:166)
org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.setup(DefaultContextSetupProviderImpl.java:58)
org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.setupContext(ManagedFutureTask.java:121)
org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor.beforeExecute(ManagedThreadPoolExecutor.java:109)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
java.lang.Thread.run(Thread.java:748)

      And still sets that app classloader after task execution in the reset:

      Thread.setContextClassLoader: Thread[EE-ManagedExecutorService-default-Thread-16,5,ServerService ThreadGroup] ModuleClassLoader for Module "deployment.services-1.0.4-rc1.war" from Service Module Loader
java.lang.Thread.setContextClassLoader(Thread.java:1477)
org.wildfly.security.manager.WildFlySecurityManager.setCurrentContextClassLoaderPrivileged(WildFlySecurityManager.java:1272)
org.jboss.as.ee.concurrent.handle.ClassLoaderContextHandleFactory$ClassLoaderResetContextHandle.reset(ClassLoaderContextHandleFactory.java:113)
org.jboss.as.ee.concurrent.ConcurrentContext$ChainedResetContextHandle.reset(ConcurrentContext.java:284)
org.jboss.as.ee.concurrent.DefaultContextSetupProviderImpl.reset(DefaultContextSetupProviderImpl.java:63)
org.glassfish.enterprise.concurrent.internal.ManagedFutureTask.resetContext(ManagedFutureTask.java:134)
org.glassfish.enterprise.concurrent.internal.ManagedThreadPoolExecutor.afterExecute(ManagedThreadPoolExecutor.java:90)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1157)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
java.lang.Thread.run(Thread.java:748)

      So the thread is sitting in the pool with the app classloader. Is there some way we should be able to get the context loader cleared or unset from the app loader in the reset?

      Attachments

        Issue Links

          clones

          Bug - A problem that impairs or prevents the functions of the product. JBEAP-16329 [GSS](7.2.z) ManagedExecutorService persists contextClassLoader reference to cause app classloader leaks

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Verified
          is related to

          Bug - A problem that impairs or prevents the functions of the product. WFLY-11846 Deployment classloader leak on EE Concurrency managed threads

          • Critical - To be worked on immediately following BLOCKER issues.
          • Closed

          Bug - A problem that impairs or prevents the functions of the product. WFLY-11906 Managed Executor Task Fails with CDI if created from Batchlet

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed

          Activity

            People

              emartins@redhat.com Eduardo Martins
              rhn-support-leiyu Lei Yu (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: