>> If you haven't figured it out yet, let me inform you: FOP suffers from large memory leaks.
>
>
> Where? Class names?
I haven't tracked it down that far yet; if I had, I'd submit a patch to Bugzilla.
I render hundreds of 4 page, image intensive PDFs over and over again. As FOP runs, the amount of memory on the heap it consumes continues a linear rise, over and over again, until it hits the limit specified by -Xmx, at which point it throws an OutOfMemoryException.
I conclude that the issue is with FOP, as it is the only process involved in the loop that can consume an entire 1 GB heap. Each individual process is relatively small, but when I generate so many back-to-back, it all adds up.
I have the following FOP code in my loop (Exception handling removed for readability):
FopImageFactory.resetCache();
File configDir = new File(fopHome, "conf"); File fopConfigFile = new File(configDir, "userconfig.xml"); Options options = new Options(fopConfigFile);
FileInputStream in = new FileInputStream(fopFile); FileOutputStream out = new FileOutputStream(pdfFile); Driver driver = new Driver(new InputSource(in), out);
driver.setRenderer(Driver.RENDER_PDF); driver.run();
in.close(); out.close();
If I'm doing something wrong, please point it out. Otherwise, it seems pretty obvious to me that FOP is the culprit. If you like, I can start gathering metrics from the JVM itself. I don't own a commercial profiling utility, otherwise I'd run that.
Ben
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
