[#2587] - Infinity loop when horizontal print order + multiple Columns

Bug report
Project: Severity:
Component: Reproducibility:
Assigned to:


I just designed a label report that is a master report with just a groupheaderband (100 pixel in height & printing at each page) with some fields and a SubReport in detail band (30 pixel in height).
So finally master report is 130 pixel in report height.
That's fine so far.

the SubReport is defined as 10 columns, a horizontal print order and just a simple detail band (10 pixel) with one TextField placed on it.

If I have just 30 detail records at SubReport it works fine and I got:
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 |

But when i have 31 (or more) records the Server (running within J2EE app) doesn't finish the filling process and I don't get any JRPrint Object.

I know that horizontal reports don't stretch but in this case they should or at least an exception like "Multiple Columns reaching predefined band height in horizontal report. Report can't be run!" should be thrown instead of going into an infinity loop as it seems to be now. (I have to restart the server-app to get the CPU time down from 100%)


Package icon JRLabelSample.zip5.72 KB
C-Box's picture
Joined: Jul 19 2006 - 5:58pm
Last seen: 2 months 3 weeks ago




Try use the REPORT_MAX_COUNT built-in parameter to make sure there are no more than 30 records displayed.

Some JRXML files would be helpful to understand the problem.



Hi Teodor,

i do attach a ZIP File containing both JRXML (unfortunately not for simple test, as again our complex structure) and a sample Output.

(it\'s not a nice one... but a customer just want\'s it! :-) )

To set the REPORT_MAX parameter would mean for us, some new database fields at our printTemplateSets to let the user store the max records for the PrintTemplateSet. (just for this case) ... but I can\'t know from design what the max number is (except I make an own property in JRXML that is parsed before fillung) ... would be nice if you find a design error or any other solution.

regards again from today windy Dresden/Germany



The infinite loop is not caused by an overflowing detail band on a horizontal report. In your sample, only the subreport has printOrder=Horizontal, and the detail band on the subreport does not stretch. The entire subreport overflows, which causes the master detail band (on which the subreport is placed) to overflow; but the master report has printOrder=Vertical so its detail band is allowed to overflow. If the master report would have printOrder=Horizontal, you would have an exception at fill time.

The infinite loop is actually caused by the fact that the subreport is placed at y = -5, which confuses the engine and makes the subreport believe that it never has enough space to print after the first overflow. We need to investigate this further and determine whether we can come up with a fix for this case.