Issue Details (XML | Word | Printable)

Key: NUCCORE-552
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: Yang ZHONG
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.
DataNucleus Core

FetchGroup#planListeners leaks memory quickly soon Out Of Memory

Created: 23/Jul/10 06:53 PM   Updated: 04/Oct/12 05:02 PM   Resolved: 06/Oct/10 11:55 AM
Component/s: Persistence
Affects Version/s: 2.0.4
Fix Version/s: 2.2.0.m2

File Attachments: 1. Zip Archive (4 kB)

Environment: Java 5, Linux

Severity: Production

 Description  « Hide
org.datanucleus.FetchGroup#planListeners holds strong references of org.datanucleus.FetchPlan, unfortunately, FetchGroup#deregisterListener is normally never invoked in RunTime. Since FetchPlan holds strong reference of org.datanucleus.ObjectManagerImpl which holds strong reference of org.datanucleus.jdo.JDOPersistenceManager, FetchGroup#planListeners leaks memory quickly soon Out Of Memory.

The Test Case to be attached, shows both FetchPlan & PersistenceManager still referenced after GC.

Just for the only purpose of Proof of Concept, following refinements seem solved the problem:
3-1. Add this into JDOPersistenceManager#close()
3-2. Add this into org.datanucleus.jdo.JDOQuery#closeAll()
        if (fetchPlan != null)
3-3. Add this into
    public void closeAll()
        if (candidates instanceof CollectionCandidates)
        else if (candidates instanceof Extent)

Now the Test Case shows both FetchPlan & PersistenceManager GCed!

However, neither is user obligated to close()/clossAll(), nor should a JDO implementation count on so. Therefore, I personally think the real fix should be weakly referencing FetchGroup#planListeners elements, such as WeakHashMap#keySet().

After the real fix, both "pm.close();" & "query.closeAll();" should be commented out of the Test Case to verify the fix.

Given the weakly referencing fix, I personally still recommend above code change as they help GC.

Sort Order: Ascending order - Click to sort in descending order
Yang ZHONG added a comment - 23/Jul/10 07:04 PM
It seems the latest FetchGroup#planListeners (2.1.1) has the same problem of strongly referencing FetchPlan.

Yang ZHONG added a comment - 23/Jul/10 08:05 PM
Do we have other "listeners"? We may want to apply weakly referencing to all of them in general.

Andy Jefferson added a comment - 20/Sep/10 01:38 PM
As mentioned many times before, we have no time for "Proof of Concept". If you have some proposed fix then "patch" is the accepted format, nothing more.

Andy Jefferson added a comment - 06/Oct/10 11:55 AM
Added FetchPlan.clearGroups to Query.closeAll, and also to DefaultCandidateExtent.closeAll.
ObjectManager.close() already did clear out the fetch plan.
Can't reproduce any such problem.