Community
Participate
Working Groups
Steps to reproduce: 1) create a JPA project 2) add several entities 3) open the JPA perspective 4) open some entity 5) select the entity and its properties 6) rebuild the project Repeat the steps 4-6. After a while, depending on the size of the project and the JVM heap size, you will get either an OOM exception or "no more handles" SWT error. You can also see that every project rebuilding leaks thousands JPA objects. The issue comes because, for an individual type of JPA node, JpaDetailsView remembers the JpaDetailsPageManager objects in the pageManagers hash map. The key is an object of the type JpaStructureNode.ContextType. The JpaStructureNode.ContextType implements hashCode, but JpaPlatform (GenericJpaPlatorm) doesn't. Since a JPA platform is created in the jpa post-build listener when rebuilding a project, JpaDetailsView allocates a new page manager for all nodes. This causes a memory leak because every page manager allocates SWT resources and adds a lot of JPA listeners. The page managers are disposed when closing the JpaDetailsView, but users rarely close this view. The attached patch (against WTP 3.4.2RC2 - the v201301092252 tag) fixes the issue by adding the equals/hashCode methods to GenericJpaPlatform. I think it is enough to add the id field to equals/hashCode because it is unique. Other implementations of the JPAPlatform interface would also need to implement equals/hashCode. The issue doesn't happen in the jpa master because it caches the platform when the platform is created the first time and doesn't create it again.
Created attachment 226334 [details] A patch
I'm sorry we took so long to get to this bug; as we had a few miscommunications and did not realize this concerned Juno SR2. As you say in the initial description, this is not a problem in Kepler. But this bug probably came in too late to be part of Juno SR2; as we had already finished and tested our final build. I am setting the Target Milestone to 3.2.3; so if we ever have an SR3 or something like that, this bug will be fixed there. Thank you for the patch. I think a safer fix in an SR would be to change the implementations of JpaStructureNode.ContextType.hashCode() and .equals(Object) to use JpaPlatform.getId() instead of using the JpaPlatform directly. This is a bit safer than changing the contract of JpaPlatform for adopters. Also, I think a workaround to this leak would be to simply close and re-open the JPA Details view.
Fixed in Kepler and later. https://dev.eclipse.org/mhonarc/lists/wtp-dev/msg08911.html
Created attachment 244692 [details] Sample project to reproduce the issue Sample project to reproduce the issue Steps: Import latest m2e code from master branch debug as Eclipse Application Import the maven project from attached.
(In reply to wei cai from comment #4) > Created attachment 244692 [details] > Sample project to reproduce the issue > > Sample project to reproduce the issue > > Steps: > Import latest m2e code from master branch > debug as Eclipse Application > Import the maven project from attached. Wrong post, sorry for the spam
