[
https://issues.apache.org/jira/browse/MYFACES-4722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17950624#comment-17950624
]
Volodymyr Siedlecki commented on MYFACES-4722:
----------------------------------------------
Hmm. I see your point. It doesn't looked like we keep any references to it (as
per the spec for none scoped beans). As you can see in the code below, we do
nothing with it:
[https://github.com/apache/myfaces/blob/2.3.x/impl/src/main/java/org/apache/myfaces/el/unified/resolver/ManagedBeanResolver.java#L88-L94]
It looks like the only references (via memory dump) are here:
Class Name
| Shallow Heap | Retained Heap
-------------------------------------------------------------------------------------------------------------------
foo.ManagedBean$Unscoped @ 0x7e30b7b38
| 24 | 16,777,304
|- referent foo.ManagedBean$Reference @ 0x7e25cb3e8
| 32 | 88
|- keyRef org.jboss.as.web.common.ConcurrentReferenceHashMap$HashEntry @
0x7e3197740| 32 | 304
'- instance org.jboss.as.naming.ImmediateManagedReference @ 0x7e3197890
| 16 | 16
-------------------------------------------------------------------------------------------------------------------
But that said, I think we can fix this by simply destroying it once it's last
used in the code. Let see what fix I can create here.
And this is just a bit of a gray area since PreDestroy is not guaranteed to be
called on None scoped beans ( based on my understanding).
> 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)
