[jboss-jira] [JBoss JIRA] (WFLY-12676) memory leak, org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner is keeping deployment in memory after undeployment

[Scott Marlow (Jira)]

     [ https://issues.jboss.org/browse/WFLY-12676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-12676:
--------------------------------
    Issue Type: Bug  (was: Task)


> memory leak, org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner is keeping deployment in memory after undeployment
> --------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-12676
>                 URL: https://issues.jboss.org/browse/WFLY-12676
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 18.0.0.Final
>            Reporter: Scott Marlow
>            Assignee: Stefano Maestri
>            Priority: Blocker
>             Fix For: 19.0.0.Beta1
>
>         Attachments: 2lc.jar, java_pid12802.0001.zip, jcaleakmarlow.txt
>
>
> As part of looking at [WFLY-12671], I found that org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover$IdleRemoverRunner is leaking the application classloader (after undeployment) via org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory originalTCCL being kept after undeployment.
> See attached jcaleakmarlow.txt (also attached to [WFLY-12671]), which shows the leak.
> I tried waiting a few minutes after undeployment and the leak was still there.  I also tried an even simpler app (2lc.jar) and still there is a leak.  I also attached the heapdump (java_pid12802.0001.zip)
> To recreate:
> * Deploy simple (no app code will be executed) 2lc.jar app.
> * Undeploy by doing "rm 2lc.jar.deployed" in wildfly/standalone/deployments
> * Look at memory with MAT or other memory leak tool.



--
This message was sent by Atlassian Jira
(v7.13.8#713008)