For various reasons, it is possible for the JasperReports engine to enter into an infinite loop while filling a report. Within this infinite loop, memory is slowly consumed until an OutOfMemoryError occurs, thus rendering the JVM useless until is is restarted. This behavior has been documented many times on this forum, and the typical response is that a report design issue is to blame.
In my opinion, this makes JasperReports a danger to run in a production environment. Our application allows users to create their own reports and run them on the system. If they make a "mistake" on the design, however, they can actually cause a memory-chewing infinite loop on the production system.
Is this going to be addressed in a future release? Aside from this problem, JasperReports is a great product. This is definitely a huge concern for anyone wanting to integrate it into a mission critical application.
Post edited by: mmastrangelo, at: 2006/09/28 15:35
In my opinion, this makes JasperReports a danger to run in a production environment. Our application allows users to create their own reports and run them on the system. If they make a "mistake" on the design, however, they can actually cause a memory-chewing infinite loop on the production system.
Is this going to be addressed in a future release? Aside from this problem, JasperReports is a great product. This is definitely a huge concern for anyone wanting to integrate it into a mission critical application.
Post edited by: mmastrangelo, at: 2006/09/28 15:35
17 Answers:
Posted on September 28, 2006 at 5:19pm
Teodor,
Thanks for replying. We have addressed this issue by introducing a tolerance level in JRVerticalFiller. The tolerance level specifies the number of loops to allow; if it is exceeded, an exception is thrown.
A possible solution could be to add a new attribute to the report design XML that allows users to specify such a tolerance level. This way it could be tailored to the needs of the report.
Thanks,
Matt
Thanks for replying. We have addressed this issue by introducing a tolerance level in JRVerticalFiller. The tolerance level specifies the number of loops to allow; if it is exceeded, an exception is thrown.
A possible solution could be to add a new attribute to the report design XML that allows users to specify such a tolerance level. This way it could be tailored to the needs of the report.
Thanks,
Matt
Posted on October 10, 2006 at 3:04pm
Hello,
The tolerance level is a solution I implemented on my own by changing the source code. It is not part of JasperReports.
I suggested this as a possible solution to prevent the infinite looping. I would be willing to share this code if Teodor thinks it could be useful.
Matt
Post edited by: mmastrangelo, at: 2006/10/10 15:07
The tolerance level is a solution I implemented on my own by changing the source code. It is not part of JasperReports.
I suggested this as a possible solution to prevent the infinite looping. I would be willing to share this code if Teodor thinks it could be useful.
Matt
Post edited by: mmastrangelo, at: 2006/10/10 15:07
Posted on October 10, 2006 at 3:39pm
Hello,
Well I am in a situation where extremely large reports are possible and I want to put a limit to the size of a particular report, so this tolerance level seems like the perfect solution because I am gettin out of memory errors on some reports. I would really appreciate your enhancement, unless there is a standard way to do this within jasper already.
Well I am in a situation where extremely large reports are possible and I want to put a limit to the size of a particular report, so this tolerance level seems like the perfect solution because I am gettin out of memory errors on some reports. I would really appreciate your enhancement, unless there is a standard way to do this within jasper already.
Posted on October 11, 2006 at 1:20pm
Hi,
Generating very large reports is not a problem if you rely on a virtualizer.
Check the supplied /demo/samples/virtualizer sample.
As for the tolerance level solution, Matt, please feel free and post it as a patch here:
http://jasperforge.org/sf/tracker/do/listArtifacts/projects.jasperreport...
Thank you,
Teodor
Generating very large reports is not a problem if you rely on a virtualizer.
Check the supplied /demo/samples/virtualizer sample.
As for the tolerance level solution, Matt, please feel free and post it as a patch here:
http://jasperforge.org/sf/tracker/do/listArtifacts/projects.jasperreport...
Thank you,
Teodor
Posted on October 30, 2006 at 10:46am
Hi,
Matt did not post yet his patch.
We have thought about such a solution lately, but did not do anything in the code yet.
Note that even if we are going to do something about abruptly getting out of infinite loops, it will not solve the problem with your report templates not working.
This is because they have a layout problem and you need to review and refactor them to avoid it. Otherwise, the reports will still break, even with such patch in place.
So if the deadline is approaching, you'd be better off rearranging the structure of your report template, to prevent infinit loops. Avoid using large bands and paying attention to subreports.
I hope this helps.
Teodor
Matt did not post yet his patch.
We have thought about such a solution lately, but did not do anything in the code yet.
Note that even if we are going to do something about abruptly getting out of infinite loops, it will not solve the problem with your report templates not working.
This is because they have a layout problem and you need to review and refactor them to avoid it. Otherwise, the reports will still break, even with such patch in place.
So if the deadline is approaching, you'd be better off rearranging the structure of your report template, to prevent infinit loops. Avoid using large bands and paying attention to subreports.
I hope this helps.
Teodor
Posted on November 2, 2006 at 7:33am
Hello teodord:
I have solve the Infinite looping by re-layout a new report...~_~"
My partner has find out if a band large then some value,
the report will crashed
We are not sure the certainty value yet.
.
.
By the way, where I will find the "tolerance level setting
"?
Will it take some effect?
Thanks for your reply & suggestion:cheer:
--
We are coming from TAIWAN
I have solve the Infinite looping by re-layout a new report...~_~"
My partner has find out if a band large then some value,
the report will crashed
We are not sure the certainty value yet.
.
.
By the way, where I will find the "tolerance level setting
"?
Will it take some effect?
Thanks for your reply & suggestion:cheer:
--
We are coming from TAIWAN
Posted on October 24, 2007 at 10:21am
Hi,
I have the same kind of problem :
java.lang.OutOfMemoryError: Java heap space
net.sf.jasperreports.engine.JRRuntimeException: java.lang.OutOfMemoryError: Java heap space
at net.sf.jasperreports.engine.fill.JRFillSubreport.prepare(JRFillSubreport.java:625)
at net.sf.jasperreports.engine.fill.JRFillElementContainer.prepareElements(JRFillElementContainer.java:343)
In my report, I have 2 subreports. In debuggage, I see that the program fill report, subreport1, subreport2, subreport2, subreport1, subreport1, subreport1 ...
It's normal ?
The problem run in a database but not in other database. It's data problem ?
I'm desperate ... an idea please ??
I have the same kind of problem :
java.lang.OutOfMemoryError: Java heap space
net.sf.jasperreports.engine.JRRuntimeException: java.lang.OutOfMemoryError: Java heap space
at net.sf.jasperreports.engine.fill.JRFillSubreport.prepare(JRFillSubreport.java:625)
at net.sf.jasperreports.engine.fill.JRFillElementContainer.prepareElements(JRFillElementContainer.java:343)
In my report, I have 2 subreports. In debuggage, I see that the program fill report, subreport1, subreport2, subreport2, subreport1, subreport1, subreport1 ...
It's normal ?
The problem run in a database but not in other database. It's data problem ?
I'm desperate ... an idea please ??
Posted on November 13, 2007 at 10:23pm
Hi,
I have the exact same problem with the subreport that ends up in a infinite loop. What I noticed is that when rendering the report, the subreport datasource call keeps rewinding, ending up in an infinite loop (next(), ..., next(), moveFirst(), next()...).
The subreport is in the detail section of the main report. This seems to happen only when the subreport is big enough to cause the report to overflow to more than 1 page. If the report can fit in 1 page, the report can be generated without any problem.
If this is a report layout issue, how do I fix the report layout? What do I have to look out for when designing the report to avoid the infinite loop problem?
Thanks in advance.
Henry
I have the exact same problem with the subreport that ends up in a infinite loop. What I noticed is that when rendering the report, the subreport datasource call keeps rewinding, ending up in an infinite loop (next(), ..., next(), moveFirst(), next()...).
The subreport is in the detail section of the main report. This seems to happen only when the subreport is big enough to cause the report to overflow to more than 1 page. If the report can fit in 1 page, the report can be generated without any problem.
If this is a report layout issue, how do I fix the report layout? What do I have to look out for when designing the report to avoid the infinite loop problem?
Thanks in advance.
Henry
Posted on January 16, 2008 at 8:31pm
Hi,
Are there any work done in regards to prevent the infinite loop from happening? I have just tested the same report with version 2.0.4 and it still have the infinite loop problem. I debugged it and it boils down to the this snippet JRVerticalFiller.fillColumnBand() that ends up in an infinite loop when filling the detail section.
Are there any work done in regards to prevent the infinite loop from happening? I have just tested the same report with version 2.0.4 and it still have the infinite loop problem. I debugged it and it boils down to the this snippet JRVerticalFiller.fillColumnBand() that ends up in an infinite loop when filling the detail section.
| Code: |
<br />
while (band.willOverflow())<br />
{<br />
fillColumnBreak(evaluation, evaluation);<br />
printBand = band.fill(columnFooterOffsetY - offsetY - band.getHeight());<br />
<br />
fillBand(printBand);<br />
offsetY += printBand.getHeight();<br />
}<br />
</td></tr></tbody></table><br />
<br />
columnFooterOffsetY = 726<br />
offsetY = 234<br />
band.getHeight() = 290<br />
<br />
It just having the exact same values when it is looping.<br />
<br />
I figured that it must have something to do with the detail section that might cause jasper into the infinite loop. In the detail section, there is a subreport and some static labels and text fields in it. So, I tried moving those labels and fields out of the detail section to the summary section and leaving the detail section contains only the subreport. This time the report is generated successfully, no infinite loop! Is that the cause of the infinite loop problem? Is it allow to have a detail band to have a subreport and at the same time with some labels and fields below the subreport?<br />
<br />
One thing I noticed is that the summary section does not fit in the rest of the first page(expected) and it is moved to the second page but the second page have no pageHeader nor pageFooter(unexpected)? I tried adding a lastPageFooter but it did not show on the summary page either? Isn't the pageHeader and pageFooter supposed to show on all pages? Any ideas?<br />
<br />
Another question - is it possible to create multiple band of the same band type, e.g., 2 detail bands? Basically, I want each detail band to hold certain fields and has its own band properties.<br />
<br />
Thanks in advance for your responses.<br />
<br />
Henry |
Posted on January 16, 2008 at 8:55pm
Henry,
I also identified that as the infinite while loop. This behavior has been very problematic for us as we allow users to customize their own reports in a production environment.
To address this, I have created a forked version of JRVerticalFiller that implements a tolerance level of 100 max fill attempts. This seems to have greatly reduced the occurrences of the infinite loop.
To implement this, the code snippet changes as follows:
I also identified that as the infinite while loop. This behavior has been very problematic for us as we allow users to customize their own reports in a production environment.
To address this, I have created a forked version of JRVerticalFiller that implements a tolerance level of 100 max fill attempts. This seems to have greatly reduced the occurrences of the infinite loop.
To implement this, the code snippet changes as follows:
| Code: |
<br />
while (band.willOverflow())<br />
{<br />
fillPageBreak(false, evaluation, evaluation, true);<br />
<br />
printBand = band.fill(columnFooterOffsetY - offsetY - band.getHeight());<br />
<br />
fillBand(printBand);<br />
offsetY += printBand.getHeight();<br />
<br />
loopCount++;<br />
<br />
if (loopCount > MAX_FILL_ATTEMPTS)<br />
{<br />
throw new JRException("Max page band fill attempts exceeded"«»);<br />
}<br />
}<br />
</td></tr></tbody></table><br />
<br />
Ultimately, it would be nice if this behavior was built into the JasperReports engine. The MAX_FILL_ATTEMPTS constant could become an optional parameter.<br />
<br />
Hope this helps. |
