Details
-
Bug
-
Resolution: Cannot Reproduce
-
Major
-
None
-
5.0-rc-1
-
None
-
Unknown
-
Description
We're using Xalan 2.7.1 which suffers from https://issues.apache.org/jira/browse/XALANJ-2195 (see also https://jira.atlassian.com/browse/CONF-14988).
The problem is that Xalan's XMLReaderManager stores SAXParser instances in a threadlocal variable but it never frees them. We use Xalan when generating PDFs (in PdfExportImpl.renderXSLFO()).
The other issue is that we set a PDFURIResolver in the FOUserAgent which itself contains a XWikiContext and the FOUserAgent is held by the SAXParser.
On the attached screenshot we can see 68 instances of SAXParser in memory in threadlocals. This corresponds to the number of Tomcat threads that have done PDF exports. They take a total of 44MB. By default Tomcat has a threadpool of 200, which means the memory usage can (and will) increase to at least 129MB and that's provided that Tomcat doesn't garbage threads (if it does then it's a real memory leak).
There's a patch in https://issues.jboss.org/browse/JBPAPP-7093: https://issues.jboss.org/secure/attachment/12346686/xalan-j2-XALANJ-2195.patch-v2
The effect is that the SAXParser won't be cached anymore but as discussed at https://issues.apache.org/jira/browse/XALANJ-2195?focusedCommentId=12451748&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12451748 it shouldn't be a real issue.
I propose to try to apply this patch on xwiki.org, monitor the memory usage and if it works nicely, then deploy a patched xalan in the XWiki maven repository.
Attachments
Issue Links
- is related to
-
XCOMMONS-1891 Stop bundling Xalan
- Closed