[
https://issues.apache.org/jira/browse/TOMEE-4560?focusedWorklogId=999767&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-999767
]
ASF GitHub Bot logged work on TOMEE-4560:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 13/Jan/26 01:32
Start Date: 13/Jan/26 01:32
Worklog Time Spent: 10m
Work Description: dblevins commented on PR #2408:
URL: https://github.com/apache/tomee/pull/2408#issuecomment-3741369242
Hi All,
First, @kartiksirigeri thank you so much for taking the initiative to try
and fix this. It's a big code base and you dug right in. That says a lot of
very good things about you.
I can verify this is a memory leak. Some notes first.
It's not legal to put `@Remove` on the interface as this annotation is
usable on the bean class only. We do have validation to check for this common
mistake and the test case does have a warning stating the annotation was
ignored:
```
Jan 12, 2026 3:23:23 PM org.apache.openejb.util.LogStreamAsync run
WARNING: WARN ... MyBean: Ignoring @Remove used on interface
org.apache.openejb.core.stateful.StatefulBeanRegistryCleanupTest$MyBeanInterface
method cleanup. Annotation only usable on the bean class.
Jan 12, 2026 3:23:23 PM org.apache.openejb.util.LogStreamAsync run
WARNING: WARN ... MyBean2: Ignoring @Remove used on interface
org.apache.openejb.core.stateful.StatefulBeanRegistryCleanupTest$MyBeanInterface2
method cleanup. Annotation only usable on the bean class.
```
The upshot of this is that the fix checks the interface for `@Remove` and is
not valid. It also causes a new leak in the scenario where the interface was
illegally annotated `@Remove` and the bean class has no `@Remove` method. The
result is that the handler is invalidated while the actual stateful instance
stays living. The container sees `cleanup()` as a regular business method and
simply invokes it and does not remove the bean instance.
This all said, the handler leak discovered is still very valid. If you were
to move the `@Remove` annotation to the `cleanup()` method defined in the bean
class, the handler reference in the registry would still not get cleaned up
when it's called.
I dug through the code looking for a way to get the knowledge that `cleanup`
is a remove method somehow communicated to the Handler, but do not see any good
way to do that. The actual mapping of what methods are remove methods is
inside private fields accessible to the StatefulContainer only. That is by
design.
I dug through the code trying to refresh my memory on why we even have a
registry in the first place and came to the conclusion it might be something we
could potentially remove entirely. We'd only be able to do that on the TomEE
11 branch and before it goes final.
@kartiksirigeri if that's something you might be interested taking the lead
on, join the dev list (mailto:[email protected]) and we can talk
more there.
Issue Time Tracking
-------------------
Worklog Id: (was: 999767)
Time Spent: 1h 10m (was: 1h)
> Memory leak for EJB3 stateful bean
> ----------------------------------
>
> Key: TOMEE-4560
> URL: https://issues.apache.org/jira/browse/TOMEE-4560
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
> Affects Versions: 8.0.16
> Reporter: Kartik Sirigeri
> Priority: Major
> Attachments: EjbProxyHandler_EJB2.png, EjbProxyHandler_EJB3.png,
> test_project.zip
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The bean references are not getting removed from
> ProxyRegistry.liveHandleRegistry map when the the method annotated wtih
> '@Remove' annotation for EJB3 stateful bean is invoked. While the call for
> remove method on EJB2 stateful beans removes the entry from
> ProxyRegistry.liveHandleRegistry map immmediately. It seems the
> EjbObjectProxyHandler._invoke method checks for EJB_OBJECT, EJB_LOCAL type
> along with the operation type, this check fails for EJB3 beans and the beans
> are not removed from the ProxyRegistry.liveHandleRegistry map unless any
> business methods are invoked which would invaldiate the map due to
> InvalidateReferenceException. This causes a memory leak unless any business
> method is called after the invocation of @Remove method in EJB3.
>
> Snapshot of the debug flow attached along with the test code
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
