[
https://issues.apache.org/jira/browse/TOMEE-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17654613#comment-17654613
]
Thomas Lien commented on TOMEE-4120:
------------------------------------
Here's an additional thing I noticed. I'm looking at all the types of
EJBObjectHandlers and it looks like registering the EntityEJBObjectHandler in
the liveRegistryMap is pretty pointless and just bloats the map. The only
purpose the liveHandleRegistry seems to serve is to call invalidateReference in
certain scenarios like exceptions or when an entity is deleted.
Here's a breakdown of each EJBObjectHandler class with EntityEJBObjectHandler.
EntityEJBObjectHandler:
Registers self in constructor but invalidateReference overridden to do nothing.
Why register at all then? Probably can just remove registerHandler(registryId,
this) from the constructor as an additional change.
SingletonEJBObjectHandler:
Does not register self in constructor. invalidateReference overridden to do
nothing. This seems fine.
StatefulEJBObjectHandler:
registers self in constructor. invalidateReference will set isInvalidReference
to true. This seems fine.
StaelessEJBObjectHandler:
does not register self in constructor. invalidateReference overridden to do
nothing. This seems fine.
> Remote EJB2 BMP Memory Leak
> ---------------------------
>
> Key: TOMEE-4120
> URL: https://issues.apache.org/jira/browse/TOMEE-4120
> Project: TomEE
> Issue Type: Bug
> Components: TomEE Core Server
> Affects Versions: 8.0.13
> Environment: I am using apache-tomee-plus-8.0.13 under windows 10 and
> jdk 8.
> Reporter: Thomas Lien
> Priority: Critical
> Attachments: mem1.png, mem2.png, mem3.png, memoryleak.png,
> test.ear.zip, testjar-src.zip
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> I'm seeing a significant memory leak when loading ejb2 bmps remotely. I've
> found that any ejb2 bmp finder function has a leak on on the client side. The
> problem eventually causes our client application to crash with an out of
> memory error.
> Below is a simple main function I made to demonstrate. If I run this program
> below using a single ejb2 findByPrimaryKey call, memory will grow rapidly. I
> traced it down using the Eclipse Memory Profiler to the
> org.apache.openejb.client.EJBInvocationHandler class retaining memory in a
> ConcurrentHashMap field called liveHandleRegistry. I can see "BMPTestHome:1"
> as the key and a HashSet of WeakReferences as values. Attaching screenshot of
> the eclipse memory profiler which continues to grow the longer the program
> runs (memoryleak.png).
> {code:java}
> package test;
> import javax.naming.InitialContext;
> public class LookupMemTest {
> public static void main(String[] args) throws Exception {
> System.setProperty("java.naming.factory.initial",
> "org.apache.openejb.client.RemoteInitialContextFactory");
> System.setProperty("java.naming.provider.url",
> "http://127.0.0.1:8080/tomee/ejb";);
> InitialContext ctx = new InitialContext();
> BMPTestHome bmpTestHome =
> (BMPTestHome)ctx.lookup("BMPTestHome");
> while (!Thread.currentThread().isInterrupted()) {
> bmpTestHome.findByPrimaryKey(new BMPTestPK(1));
> Thread.sleep(5);
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
