[jboss-jira] [JBoss JIRA] (WFLY-12446) Memory leak in StatelessSessionComponent

[Jaikiran Pai (Jira)]

    [ https://issues.jboss.org/browse/WFLY-12446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13781991#comment-13781991 ] 

Jaikiran Pai commented on WFLY-12446:
-------------------------------------

A quick look at (my locally generated) heap dump suggests that this might need some investigation from the Weld team. I have attached wfly-12446.png which shows the heap usage. So a stateless session component (bean) uses a strict-max bean instance pool. That bean instance pool has 128 entries (which correspond to 128 instances of the stateless bean). This number is correct since it's the max number of bean instances allowed (by default) in that pool. So far so good. However, the total memory usage of this strict max pool (containing 128 entries) translates to 1.5 GB (as shown in the image). This is not good. Digging further, it shows that _each entry_ holds on to a 12 MB List through the org.jboss.weld.contexts.CreationalContextImpl#dependentInstances field. So 12 MB * 128 = 1.5 GB (approximately) which matches the reported numbers.
It's odd that the List is that huge, but I haven't yet looked why or what it holds on to. Someone from Weld might be able to understand this, a bit more quickly. 
FWIW, the stateless component in this attached application which has these 128 entries is the "CommandServiceBean".

> Memory leak in StatelessSessionComponent
> ----------------------------------------
>
>                 Key: WFLY-12446
>                 URL: https://issues.jboss.org/browse/WFLY-12446
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 17.0.1.Final
>            Reporter: Joerg Baesner
>            Assignee: Cheng Fang
>            Priority: Major
>         Attachments: dump.png, playground-jee8.zip, server.log.gz, wfly-12446-heap-dump.png
>
>
> When running the attached reproducer application and doing a memory analysis afterwards, it looks like a memory leak, e. g.
> {code}
> One instance of "org.jboss.as.ejb3.component.stateless.StatelessSessionComponent" loaded by "org.jboss.modules.ModuleClassLoader @ 0x5e0fbc2e0" occupies 936,593,520 (96.13%) bytes. The memory is accumulated in one instance of "java.util.concurrent.ConcurrentLinkedQueue$Node" loaded by "<system class loader>".
> {code}



--
This message was sent by Atlassian Jira
(v7.13.5#713005)