| Summary: | [PATCH] CSS scanner keeps multiple file handles to UserAgentStyleSheet.css open | ||
|---|---|---|---|
| Product: | Batik - Now in Jira | Reporter: | Martin Kaeser <m.kaeser> |
| Component: | CSS | Assignee: | Batik Developer's Mailing list <batik-dev> |
| Status: | NEW --- | ||
| Severity: | normal | CC: | dchwalisz |
| Priority: | P2 | Keywords: | PatchAvailable |
| Version: | 1.7 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | Diffs for Parser.java and Scanner.java | ||
Created attachment 23399 [details] Diffs for Parser.java and Scanner.java Our software uses the CSS component of Batik. It's executed on a dedicated server system. Several times a big number of file handles (> 100) to the Batik resource file UserAgentStyleSheet.css remained open, that forced us to restart the server. We managed to track down the problem in the Batik source code: In SVGDOMImplementation and SVG12DOMImplementation the above mentioned resource file is parsed, which leads to org.apache.batik.css.parser.Parser.parseStyleSheet(InputSource source). At the beginning of this method a Scanner instance is created but at the end it isn't destroyed (only set to null). The org.apache.batik.css.parser.Scanner holds an instance of org.apache.batik.util.io.NormalizingReader that needs to be closed to free the file handle. As the scanner and the reader are not destroyed after the end of their usage, the freeing of the file handle relies on the Java garbage collector. Especially on server systems with lots of resources this can take a long time. To improve the performance in this respect we applied a patch to our version of Batik (based on batik-src-1.7.zip). With this post we send you unifed diff files for Parser.java and Scanner.java. We would really appreciate it if you could include a fix for this matter in the next version of Batik.