We are using JaserReports to create reports on a J2EE platform (Websphere).
We have an archive PDF report that we are generating with about 2000 pages. This is being done in several steps. The main page has one person's daily work (timecard object), and it has up to eight sub reports. The data for each subreport will be about a page (some have more) and some subreports will not have data. Each sub-report is linked to a JRDataSource that points to a data collection with the data. There is less than 100 items in any data source. There is no actual database connections.
After the main report is generated we call i-text to copy the main single report into a multiple page report. This is done until all cards are processed.
This is working and the report generates in time. We have noticed that threads are being allocated and never freed up. This means that after three or four generations of the report, we receive a memory error and the JVM dumps :pinch: . The threads appear to be locking the memory it was using.
We removed all but the generation of the report, and the threads stay allocated. If we do not call Jasper reports, the threads do not get locked. We have virtualized the report and this sped up the report,
but the problem continues. We also set the margin of the sub reports to 0 just incase that was causing a type of loop.
We are using JasperReports 1.2.3
Any ideas?
Post edited by: osiramon, at: 2006/08/15 16:20
Post edited by: osiramon, at: 2006/08/15 18:16
We have an archive PDF report that we are generating with about 2000 pages. This is being done in several steps. The main page has one person's daily work (timecard object), and it has up to eight sub reports. The data for each subreport will be about a page (some have more) and some subreports will not have data. Each sub-report is linked to a JRDataSource that points to a data collection with the data. There is less than 100 items in any data source. There is no actual database connections.
After the main report is generated we call i-text to copy the main single report into a multiple page report. This is done until all cards are processed.
This is working and the report generates in time. We have noticed that threads are being allocated and never freed up. This means that after three or four generations of the report, we receive a memory error and the JVM dumps :pinch: . The threads appear to be locking the memory it was using.
We removed all but the generation of the report, and the threads stay allocated. If we do not call Jasper reports, the threads do not get locked. We have virtualized the report and this sped up the report,
but the problem continues. We also set the margin of the sub reports to 0 just incase that was causing a type of loop.
We are using JasperReports 1.2.3
Any ideas?
Post edited by: osiramon, at: 2006/08/15 16:20
Post edited by: osiramon, at: 2006/08/15 18:16
2 Answers:
Posted on August 16, 2006 at 8:33pm
We have found what the problem was. The main report page had Print Header on New page set to true, and the sub-reports had the same setting set to true. Together this caused the loop when the sub report went to a second page. Removing the Print header on new page fromt he master report areas corrected this and broke the loop.
It's strange that the report did print however since the loop condition should have kept on going.
It's strange that the report did print however since the loop condition should have kept on going.
Posted on August 21, 2006 at 5:12pm
Hi,
The use of threads for subreport filling can be turned off by setting a system property.
Check the jasperreports.properties inside the /demo/samples/subreport sample shipped with our project source files to see the needed config line.
If you set that system property as shown, JR will use JavaFlow Continuations instead of multi-threading and maybe your problem would go away.
I hope this helps.
Teodor
The use of threads for subreport filling can be turned off by setting a system property.
Check the jasperreports.properties inside the /demo/samples/subreport sample shipped with our project source files to see the needed config line.
If you set that system property as shown, JR will use JavaFlow Continuations instead of multi-threading and maybe your problem would go away.
I hope this helps.
Teodor
