subreport out of memory - can't recreate in dev

[rcmpjames]

Greetings,

 

I am getting the following stack trace in a PROD environment, but cannot recreate in my DEV (with same data), so I assume it is not related to the "known" issue of the subreports extending beyond their boundaries within their respoective parents. Any other ideas? JasperReports has been rendered useless in our PROD environment...

 

java.lang.OutOfMemoryError

NESTED BY :net.sf.jasperreports.engine.JRRuntimeException at net.sf.jasperreports.engine.fill.JRFillSubreport.prepare(JRFillSubreport.java:583) at net.sf.jasperreports.engine.fill.JRFillElementContainer.prepareElements(JRFillElementContainer.java:345) at net.sf.jasperreports.engine.fill.JRFillBand.fill(JRFillBand.java:311) at net.sf.jasperreports.engine.fill.JRFillBand.fill(JRFillBand.java:275) at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillColumnBand(JRVerticalFiller.java:1307) at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillDetail(JRVerticalFiller.java:631) at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReportStart(JRVerticalFiller.java:228) at net.sf.jasperreports.engine.fill.JRVerticalFiller.fillReport(JRVerticalFiller.java:128) at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:750) at net.sf.jasperreports.engine.fill.JRBaseFiller.fill(JRBaseFiller.java:666) at net.sf.jasperreports.engine.fill.JRFillSubreport.fillSubreport(JRFillSubreport.java:498) at net.sf.jasperreports.engine.fill.JRSubreportRunnable.run(JRSubreportRunnable.java:63) at net.sf.jasperreports.engine.fill.JRThreadSubreportRunner.run(JRThreadSubreportRunner.java:137) at java.lang.Thread.run(Thread.java:534)Caused by: java.lang.OutOfMemoryError

[lshannon]

The only time I have seen a subreport overflow is when a subreport is placed in the "LastPageFooter" band (this band has no-where to grow too so if the subreport grows larger than the band the report breaks).

 

Can you paste the entire stack trace?

[rcmpjames]

That's the entire stack trace I get from my logs.

 

If I had a layout issue wouldn't it occur on any machine I was running on, assumig the data is the same?

 

ps - this isn't Shannon Lal, by chance...?

[lshannon]

Different Shannon :-)

 

What is the difference between Prod and your machine? Any OS differences? JVM differences? Could be a package JR depends upon that is a different version (unlikely).

 

Lets start with the OS and JVM.

[rcmpjames]

same OS, same JVM - but not much memory allocated to the JVM (200MB). Though that may be the source of the problem, one issue I have is that the JasperReports API seems to have bit it with the memory problem ...?

[lshannon]

I have worked with some very large reports and not had issues.

 

When the report is filling with data, the pages are built/stored in memory. For larger reports (more data) you sometimes have to implement a virtualizer (this moves some of the page data from memory to the file system).

 

This is something you might want to look into, but I don't think it is the issue here.

 

However I think this probably is the result of something in your report design. A loop perhaps that is consuming all the memory. Why this doesn't happen on your machine I don't know.

 

Can you post the JRXML for the subreport?

[rcmpjames]

I'll post the jrxml tomorrow, thanks. Does the virtualizer work in a clustered server environment?

[lshannon]

I would think it would. It can be configured in the jasperreports.properties file. You would need to have one of these on each machine that had a version of JR.

[rcmpjames]

Dumb Question:

 

When I render the report, I send a byteArray to a struts forward that I get from a JRExporter's Output Stream - like this:

 

Code:

...

JRExporter exporter = new JRPdfExporter();
            exporter.setParameter(JRExporterParameter.JASPER_PRINT, printer);
            exporter.setParameter(JRExporterParameter.OUTPUT_STREAM, buf);
            exporter.exportReport();

request.setAttribute( "GeneratedReport", buf.toByteArray());

...

 

Might this ByteArray be the problem?

[lshannon]

Not sure about that. Has this worked before or was this application just deployed?

 

In your dev environment do you have the same container, framework and DB?

[rcmpjames]

Yes, yes, and yes. Weird, eh? In fact, in PROD, we have 2 of the same app running - the one with issues, and a training app - identical in every way except the data source. No problems with the training app....!!!

[lshannon]

This is very weird.

 

So this happens every time? You never posted the JRXML. What I was going to look for was passed in values in the query that, when given a certain value, could result in a issue at the query level. Also for Subreports in bands that don't allow for overflows (ie: LastPageFooter).

 

You might want to consider turning on debugging in log4J for the JR JDBC QueryExcuter and the Exporter you are using. You might get a better clue as to what is going on from those outputs.

 

I am not sure where to go from here as I have a few "weird" issues of my own to solve.