exportReportToPdfFile hangs with OutOfMemoryError

[mreis]

We have a huge report consisting of ~50.000 pages. Using the JRConcurrentSwapFile we can create the JasperPrint instance without any problems (using only 128MB for -Xmx). When exporting the JasperPrint instance to PDF we get an OutOfMemoryError (not enough heap space) however.

We use the JasperExportManager.exportReportToPdfFile method - Should we rather use JasperExportManager.exportReportToPdfStream? The JRPdfExporter uses a FileInputStream as I found out - Is it better to use some other stream (wrapper) in order to solve that problem?

Any other ideas?

 

kind regards & many thanks

markus

[danielsb2]

mreis
Wrote:

We have a huge report consisting of ~50.000 pages. Using the JRConcurrentSwapFile we can create the JasperPrint instance without any problems (using only 128MB for -Xmx). When exporting the JasperPrint instance to PDF we get an OutOfMemoryError (not enough heap space) however. We use the JasperExportManager.exportReportToPdfFile method - Should we rather use JasperExportManager.exportReportToPdfStream? The JRPdfExporter uses a FileInputStream as I found out - Is it better to use some other stream (wrapper) in order to solve that problem? Any other ideas?   kind regards & many thanks markus

 

 

 

I'm with the same problem.

I use the 3 virtualizations methods (swap, file and gzip). The 3 works fine during all the filling process. But, when the aplicattion try to export to PDF, i get the OutOfMemoryError...

 

Someone know what i can do?

 

 

 

 

[lucianc]

Do you have many/repeating images in the report?

I don't understand the question regarding FileInputStream.  How exactly is FileInputStream involved here?  Are you actually talking about FileOutputStream?

Regards,

Lucian

[danielsb2]

lucianc
Wrote:

Do you have many/repeating images in the report? I don't understand the question regarding FileInputStream.  How exactly is FileInputStream involved here?  Are you actually talking about FileOutputStream? Regards, Lucian

 

 

My report is text only...

 

Basically, the report group the data by Period.

 

Period:  2008/05/27

                      Name      Occupation    Years
                     ------           --------------       ------
                     ------           --------------       ------

 

But, i have +- 50 groups, and 1000 regs for each

I atacched my class

  

Post Edited by Daniel Sousa at 12/03/08 18:24

Code:

Post Edited by Daniel Sousa at 12/03/08 18:26

Post Edited by Daniel Sousa at 12/03/08 18:34

Post Edited by Daniel Sousa at 12/03/08 18:45

[mreis]

Yes, I have 3 repeating images (the report/pdf contains ~50.000 balance sheets for different accounts and each balance sheet has 3 images - so the report/pdf contains ~150.000 images, although only 3 distinct, in the end). Does JasperReports offer options to effectively handle such situations?

Yes, I actually meant FileOutputStream - sorry.

I'm working on HP-UX (with HP's JVM). I use 128M as -Xmx. HP offers three different flavours of the java executable - java, java_q3p, and java_q4p (the main difference is that they seem to be able to reserve/use more/less system resources). If I use java_q4p (which is allowed to reserve/use more system resources than the other two flavours) instead of java the OutOfMemoryError does NOT occur - still I have -Xmx=128M.

 

kind regards,

Markus

[lucianc]

Daniel, you should only do virtualizador.setReadOnly(true) after the report is filled (i.e. after JasperFillManager.fillReport).

HTH,

Lucian

[lucianc]

mreis
Wrote:

Yes, I have 3 repeating images (the report/pdf contains ~50.000 balance sheets for different accounts and each balance sheet has 3 images - so the report/pdf contains ~150.000 images, although only 3 distinct, in the end). Does JasperReports offer options to effectively handle such situations?

This should work fine as long as caching is enabled for these images (otherwise you would effectively have 150.000 distinct images in the report, which requires a lot of memory at PDF export time).

If your images use java.lang.String imageExpressions, then caching would be enabled by default for them.  If you use other types of imageExpressions, you need to explicitly set isUsingCache="true" for the images.

HTH,

Lucian

[mreis]

Lucian,

 

why is it necessary/important to do virtualizer.setReadOnly(true) AFTER the report is filled (I also have this statement before the fillReport call)?

 

kr,

Markus

[lucianc]

mreis
Wrote:

Lucian, why is it necessary/important to do virtualizer.setReadOnly(true) AFTER the report is filled (I also have this statement before the fillReport call)? kr, Markus

It is necessary to do virtualizer.setReadOnly(true) only after filling the report, because if you do it before the report is filled, the virtualizer would not work correctly during the fill.

If you do virtualizer.setReadOnly(true) before filling the report, remove this line.

Regards,

Lucian

[mreis]

OK - do you further think that this could have caused the OutOfMemoryError when exporting to PDF?

[lucianc]

mreis
Wrote:

OK - do you further think that this could have caused the OutOfMemoryError when exporting to PDF?

I would say no, but it needs to be fixed anyway.

Have you checked whether your images are cached?

[mreis]

Yes - I have checked that (we use java.io.InputStream and checked the checkbox that says "Use caching" - in iReport).  But even if I remove the images from the report, I get the OutOfMemoryError with HP's "java" executable (with HP's "java_q4p" executable everything works fine). Did you ever encounter such problems on huge reports (our report has a bit more than 50.000 pages) or did you ever hear about HP JVM related problems?

[lucianc]

I never used HP-UX Java, so I don't have any feedback on that.

Regarding PDF export memory consumption, uncached images are the only unscaleable items that I'm aware of.  The only solution might be to do some memory profiling to see what kind of objects accumulate in the heap.

Also note that even when using virtualization, a small amount of heap space is still consumed for every new page (by a paget stub and by some swap file pointers that are kept in memory by the virtualizer).

[mreis]

Lucian, many thanks for your valueable inputs.