Bug 346671

Description Scott Hamilton 2011-05-20 09:04:47 EDT

Build Identifier: 2.6.1

HTML reports (at least those not generated thru the viewer) are treated as one long page (at least so far as I can see).  For all reports, however, the OnPageBreakLayoutPageHandle is added as a Handler and is called for each IContent that is added to the report output.

For each IContent, it is examined to see if it has an onPageBreak handler or a javaClass handler.  If either is true, it is added to a collection stored in this class so that when a page break event occurs, these events can percolate through the page content that need to know.

This is not an issue for paginated reports - as after each page the collection is cleared.

For HTML reports, however, there is only one page, and so these accumulate for the entire report.

We have a situation where we use TextItemEventAdapter Java classes to process the onRender events.

Under most conditions, an HTML report is pretty short anyway and this is not an issue, but more often than we'd like, users are creative at pushing the limits of practicality, and so we get HTML reports generated for rows in the 100,000s to millions of rows range.

What this amounts to is an out of memory error (without a very large heap, and even then if folks run multiple concurrent reports like this, there's no hope) because of the single-page nature of the HTML report and the fact that each page is contributing several (scores) of these IContent objects into this OnPageBreakLayoutPageHandle collection.

Unfortunately I'm not able to suggest a really good solution - I'm not as familiar with the BIRT code enough to do so.  If this was a paginated report (and I'm not sure how you do that for HTML), you could install a configurable page limit like you recently did for PDF (#340111).  Perhaps there would be a way to limit the # of rows processed in the main query of the report that was a configuration that could be sent to BIRT with the report run task (and if there is, let me know?).  Perhaps desupport the onPageBreak for HTML reports?  Configurable # of rows that comprise a "page" in an HTML report and just simulate a page break?

Currently we've hacked this since we don't use these page break handlers by reflectively injecting an ArrayList implementation which ignores additions to the list, and this works for us... unless and until we decide to use a page break handler.  Obviously this is not something that would work for BIRT's community given the conscious decision on our part to ignore that feature.

It is very possible that there IS a workaround already in place that I've not seen.  However, the problem remains to be thought thru... memory consumption should be considered an "only as much as is strictly necessary" for an enterprise reporting solution.

Reproducible: Always

Steps to Reproduce:
1. Create a BIRT report where content on the page has onPageBreak handlers
2. Generate the report as HTML (not thru the viewer) for a huge # of rows (100k+)
3. Watch the memory consumption grow out of control