Hi, Right now I am trying to optimize my report generation task for memory footprint. With certain level of Xmx (128m) I receive an OutOfMemoryError during exporting to pdf step on PdfDocument.close: Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at com.lowagie.text.pdf.ByteBuffer.toByteArray(Unknown Source) at com.lowagie.text.pdf.PdfContentByte.toPdf(Unknown Source) at com.lowagie.text.pdf.PdfFormXObject.<init>(Unknown Source) at com.lowagie.text.pdf.PdfTemplate.getFormXObject(Unknown Source) at com.lowagie.text.pdf.PdfWriter.addSharedObjectsToBody(Unknown Source) at com.lowagie.text.pdf.PdfWriter.close(Unknown Source) at com.lowagie.text.pdf.PdfDocument.close(Unknown Source) at com.lowagie.text.Document.close(Unknown Source) at net.sf.jasperreports.engine.export.JRPdfExporter.exportReportToStream(JRPdfExporter.java:644) at net.sf.jasperreports.engine.export.JRPdfExporter.exportReport(JRPdfExporter.java:363) As far as I am concerned this has nothing to do with virtualizers as they are active only during filling step. Lucian mentioned that lots of different images may be the reason for draining memory quickly. In my report I have about 1000 images generated dynamically via custom JRRenderable. Resulting PDF, when created, is 300 pages long and has size of about 14M (compressed). Now, my questions are: Is this the number of images you consider "many", ie am I the case you wrote about? Is there any solution/parameter/technique to optimize this step? I figured that during export garbage collector can reclaim very little memory. There is no such issue during filling. Why this happens on the PdfDocument.close method? I am not an iText expert and this bothers me a little.Thank you for any suggestions, Marcin Post Edited by marcin-k at 07/28/2010 07:59 Post Edited by marcin-k at 07/28/2010 08:00
