[ 
https://issues.apache.org/jira/browse/ODFTOOLKIT-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15546498#comment-15546498
 ] 

Svante Schubert commented on ODFTOOLKIT-300:
--------------------------------------------

I have looked into deeper into this issue.

The problem is the design of this feature given by the IBM team that forked 
once the toolkit and provided the Simple API. The usage of a static Map without 
methods to remove content might suited once their use case, but everyone would 
avoid a wording such as "production ready" for this special feature.

In the future this source code will hopefully become obsolete, when similar 
functionality is provided by the upcoming lower ODFDOM level feature 
https://issues.apache.org/jira/browse/ODFTOOLKIT-441

For now I think it is a good idea to follow the approach surfx and Daniel have 
followed and add static public method to the SelectionManager to clear the Map, 
according to surfx suggestion I will add to the inner SelectionManager of 
Selection.java

/**
 * Clears the repository being used by the SelectionManager.
 * Must be called at the end of Navigation.
 */
public static void clearRepository (){
    repository.clear();
}

> Memory Leak in ODF Simple API
> -----------------------------
>
>                 Key: ODFTOOLKIT-300
>                 URL: https://issues.apache.org/jira/browse/ODFTOOLKIT-300
>             Project: ODF Toolkit
>          Issue Type: Bug
>          Components: simple api
>    Affects Versions: 0.5-incubating
>         Environment: odfdom-java-0.8.7.jar; simple-odf-0.6.6.jar
>            Reporter: Mathias Silbermann
>            Assignee: Devin Han
>         Attachments: MemoryLeak_300.java, TestTextSelection.odt
>
>
> There is a memory leak in the ODF Simple API. I tried both, versions 0.6.6 
> and 0.6.5. It appears when running code like the examples on cookbook page
> http://incubator.apache.org/odftoolkit/simple/document/cookbook/Manipulate%20TextSearch.html
> In short, the call TextNavigation.nextSelection() leads to the leak. When you 
> look down the method's call stack, you will find that items are added to the 
> static variable "repository" of the static inner class 
> "Selection.SelectionManager". The added items are never removed from the 
> repository. One indication is that the method 
> Selection.SelectionManager.unregisterItem() is never called.
> The code works fine if text navigation is done with few documents. But when 
> its run on a server thousands of times, it will fill the JVMs memory.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to