[
https://issues.apache.org/jira/browse/ODFTOOLKIT-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15545056#comment-15545056
]
Daniel Fernández commented on ODFTOOLKIT-300:
---------------------------------------------
I'm applying a variant of @surfx workaround.
My uses of TextNavigation objects deal with them as a resource, calling a new
"TextNavigation.close()" method in a finally block after use. And this
"TextNavigation.close()" simply calls
"Selection.SelectionManager.repository.clear()".
However, this is only a workaround and I wouldn't consider it a
production-ready patch for general use (though it serves my needs). For a
starter this provokes that all accesses to TextNavigation objects should be
synchronized among them in order to avoid one thread clearing the
SelectionManager.repository that other thread -- using a different
TextNavigation object -- might still be using.
IMHO deeper changes at how the SelectionManager class is internally used should
be performed at the odftoolkit codebase. Unfortunately I am not able to provide
such general-use patch --- all I need a quick workaround to fix this issue in a
production server.
> 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)
