[
https://issues.apache.org/jira/browse/MYFACES-4722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17950120#comment-17950120
]
Volodymyr Siedlecki commented on MYFACES-4722:
----------------------------------------------
{color:#9cdcfe}I think we need to ask the WildFly team about
ConcurrentReferenceHashMap. It's holding onto the remaining references, thus
causing a leak.
Class{color}{color:#cccccc} {color}{color:#9cdcfe}Name{color}{color:#cccccc} |
{color}{color:#9cdcfe}Referenced{color}{color:#cccccc}
{color}{color:#9cdcfe}Objects{color}{color:#cccccc} |
{color}{color:#9cdcfe}Shallow{color}{color:#cccccc}
{color}{color:#9cdcfe}Heap{color}{color:#cccccc} |
{color}{color:#9cdcfe}Ref{color}{color:#cccccc}.
{color}{color:#9cdcfe}Shallow{color}{color:#cccccc}
{color}{color:#9cdcfe}Heap{color}{color:#cccccc} |
{color}{color:#9cdcfe}Retained{color}{color:#cccccc}
{color}{color:#9cdcfe}Heap{color}
{color:#6a9955}---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------{color}
{color:#d4d4d4}<{color}{color:#9cdcfe}Java{color}{color:#cccccc}
{color}{color:#9cdcfe}Local{color}{color:#d4d4d4}>{color}{color:#cccccc}
{color}{color:#9cdcfe}org{color}{color:#cccccc}.{color}{color:#4ec9b0}apache{color}{color:#cccccc}.{color}{color:#4ec9b0}myfaces{color}{color:#cccccc}.{color}{color:#4ec9b0}config{color}{color:#cccccc}.{color}{color:#4ec9b0}annotation{color}{color:#cccccc}.{color}{color:#4ec9b0}Tomcat7AnnotationLifecycleProvider{color}{color:#cccccc}
{color}
{color:#ce9178}'- instanceManagers java.util.WeakHashMap {color}
{color:#cccccc} {color}{color:#ce9178}'- table java.util.WeakHashMap$Entry[16]
{color}
{color:#cccccc} {color}{color:#ce9178}'- [0] java.util.WeakHashMap$Entry {color}
{color:#cccccc} {color}{color:#ce9178}'- value
org.wildfly.extension.undertow.deployment.UndertowJSPInstanceManager {color}
{color:#cccccc} {color}{color:#ce9178}'- webInjectionContainer
org.jboss.as.web.common.CachingWebInjectionContainer {color}
{color:#cccccc} {color}{color:#ce9178}'- references
org.jboss.as.web.common.ConcurrentReferenceHashMap {color}
{color:#cccccc} {color}{color:#ce9178}'- segments
org.jboss.as.web.common.ConcurrentReferenceHashMap$Segment[16] {color}
{color:#cccccc} {color}{color:#ce9178}'- [8]
org.jboss.as.web.common.ConcurrentReferenceHashMap$Segment {color}
{color:#cccccc} {color}{color:#ce9178}'- table
org.jboss.as.web.common.ConcurrentReferenceHashMap$HashEntry[16] {color}
{color:#cccccc} {color}{color:#ce9178}'- [12]
org.jboss.as.web.common.ConcurrentReferenceHashMap$HashEntry {color}
{color:#cccccc} {color}{color:#ce9178}'- keyRef foo.ManagedBean$Unscoped {color}
{color:#6a9955}---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------{color}
> Memory leak when using unscoped managed beans
> ---------------------------------------------
>
> Key: MYFACES-4722
> URL: https://issues.apache.org/jira/browse/MYFACES-4722
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
> Affects Versions: 2.3.11
> Environment: Linux + WildFly
> Reporter: Paul Pogonyshev
> Assignee: Volodymyr Siedlecki
> Priority: Major
> Attachments: image-2025-05-07-11-29-07-479.png,
> image-2025-05-07-13-29-24-689.png, image-2025-05-07-13-29-49-641.png,
> image-2025-05-07-13-31-03-098.png, myfaces-memory-leak.tar.gz
>
>
> When a managed bean is instantiated by MyFaces, it gets registered in some
> deployment-global map. I'm not sure about the interface involved, on WildFly
> it boils down to `CachingWebInjectionContainer`. When the bean's scope
> (request, session, etc.) is closed, the bean is removed from this map.
> However, if the bean has no scope associated, it seems to never get removed,
> essentially leaking memory. If the bean is large or references lots of
> objects, this eventually leads to OOM situation. We have observed this in
> practice.
> I created a simple reproducer project. I only tested with MyFaces 2.3 and
> WildFly 26, but the bug might also be present in newer versions as well (it
> is simply not easy for me to test as I used the same setup as for our real
> project).
> To reproduce:
> * unpack the project;
> * build it (`./gradlew clean build`);
> * deploy on WildFly;
> * visit the page (sth. like
> `http://localhost:8080/myfaces-memory-leak/test.jsf`);
> * refresh about 10-20 times (depends on WildFly settings etc.);
> * eventually OOM is triggered.
> You also don't have to wait for OOM. If you check server output (stdout) you
> can see text like this:
> NEW MANAGED BEAN: request #0
> NEW MANAGED BEAN: unscoped #1
> NEW MANAGED BEAN: unscoped #2
> NEW MANAGED BEAN: request #3
> GARBAGE-COLLECTED: request #0
> NEW MANAGED BEAN: unscoped #4
> NEW MANAGED BEAN: unscoped #5
> NEW MANAGED BEAN: request #6
> GARBAGE-COLLECTED: request #3
> ...
> I.e. managed beans with request scope get allocated and then
> garbage-collected. However, beans without associated scope never get
> garbage-collected because they are still reachable in memory.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
