Infinite Loop in JRVerticalFiller

[f.maialeal]

Hi everyone.

I know that this issue has been asked a long time ago here, but it seems that it's not fixed yet (until version 6.19.0). We had a serious problem with this. Although this bug becomes active because a bad configuration of the jrxml file, even so the class JRVerticalFiller is not processing well, entering an infinite loop of overflowing the band. I'm providing a small project with a minimal jrxml file that reproduces the issue.

Here's some instructions about the attached project:

• Requires Java 11
• After extract, enter in the extracted folder and run: mvn install
• Enter in target folder and run: java -jar jasper-infinite-loop-0.0.1-SNAPSHOT.jar

As the run process will fail in a infinite loop, the thread is configured with a timeout of 15 seconds (see the JasperInfiniteLoopApplication).

The minimal jrxml file consists of a band with a frame that has "isPrintWhenDetailOverflows=true". Inside the frame, one StaticText that behave as a column header and a List. The DataSource is relevant too. It has data for the List component filling almost an entire page. But after filling the data, the frame itself not overflows, only the band because of the remaining space at bottom. This particular situation causes the band.calculateStretchHeight() always grather than the band.getStretchHeight(), making the band overflowing forever.

Hope that a good soul takes care this issue.

[Mehak Rajkumar]

Thank you for posting to the Jaspersoft Community. Our team of experts has read your question and we are working to get you an answer as quickly as we can. If you have a Jaspersoft Professional Subscription plan, please visit https://support.tibco.com/s/ for direct access to our technical support teams offering guaranteed response times.

[anish.rai]

Thank you for your patience, we have not forgotten you. We need a little more time with our team of experts to come up with a solution. We will respond back with an answer as quickly as we can.

[anish.rai]

Thank you for your patience, we need a little more time with our team of experts to come up with a solution. We will respond back as soon as we have an answer to your question.

[teodord]

Hi, Fábio,

From the description of the problem, it appears you already understand what the cause is. Indeed, setting isPrintWhenDetailOverflows=true is the cause of the problem, coupled with the fact that the detail band overflows with white space. At the bottom of you detail band, under the frame with the list component, you have 26 pixels of white space.

So now let's think about it: do you really want your frame with the list to be rendered again in case the detail overflow onto a next page? What do you want the engine to do with the 26 pixels at the bottom of the detail? Didn't you put them because you wanted them to be kept? Or do you expect the engine to ignore them? If you want the engine to ignore them, why did you put them in the first place? The engine does not ignore the 26 pixels of white space and it just happens that the page break occurs when this white space "needs to be rendered". This is why I say "it overflows with white space".
If you put JasperReport aside for a moment and try to run the report in your head, considering the way it is expected to work as explained above, dont you enter an infinite loop in your head trying to create a new page for the remaining white space while having to render the list again, which would cause a new page break due to the white space of the bottom and then on that page you need to render the list again which would cause the page break again and again and again and again?...

You might also ask: why isn't the engine able to understand it has entered an infinite loop? Well, this is some sort of generic theoretical question of software programming that I encourage you to try find an answer for, but I hope it is not about using a counter or something. Are we in an infinite loop if 1000 pages have been created?

Or maybe you ask: why isn't the engine able to tell me my report is incorrect or inconsistent when I design it? It can't because as you see the situation depends on the runtime data. It just happens that because of the number of records in the list and maybe the values themselves, the page break occurs in the worst possible place, so this cannot be known at report design time.

And now to come back to the initial questions: is this something you really need? The list to render again when detail overflows? Do you really need that white space in the same detail band as the list, or can you preserve that white space by using a second empty detail band of height=26?

I am trying to give you report design options, because this infinite loop problem is not going to be solved any time soon. In the past we've done our best to detect infinite loop situations, but some cases are simply not solvable.

I hope this helps.

Teodor

[marcilio.grisotto]

Maybe the combination of strech and print when overflows should be avoided.

Things that stretch don´t need to overflow, I can not think of a situation where it is needed but I don´t have much experience with Jasper.

The principle to avoid the infinite loop would be:

Things that stretch should not overflow.

[teodord]

Hi, Marcilio

I think what you mean is "elements that stretch should not print again when their band overflows".

Because, contrary to what you said, elements that stretch, most of the time do overflow.

The problem here is that it not necessarily the object that stretches, which is marked as isPrintWhenDetailOverflows=true.

In Fabio's example, it is indeed the case, but that's because he prepare for us the most basic of examples, with minim number of elements involved.

But I can very well remove the reprinting flag from the list element and put it on some other element that does not itself stretch, the effect being the same.

I hope you see that the complexity of the behaviour is hard to predict and validate upfront.

Thank you,

Teodor