Significant memory consumption due to delayed evaluation (DelayedFillActions)

[anton.mazkovoi_1]

Hi,

Firstly, thank you so much for a such a robust and flexible Reporting Engine!

I have been using it for a while and recently have ran into a memory consumption issue:

I have a report (composed of multiple sub-reports) with a table of contents at the beginning of the report and each page also has its page number at the bottom.

As the contents of the report is dynamic, and hence the table of contents is dynamic, the evaluation of the Text Field that shows each page's number is set to "Master".

It appears that delaying the evaluation of text fields significantly increases memory usage needed for the report generation, as (from what I can tell) the classes used to track delayed actions use a lot of memory.

The final PDF report with about 650 pages results in a 2.5MB pdf file. However, during the execution of the report the DelayedFillActions instance takes up about 65MB. If I understand correctly, this is due to the fact that DelayedFillActions holds a reference to an instance of each page where the delayed action needs to be performed, and each page holds references to a tree of objects used to generate its contents.

If the delayed evaluation is removed (by changing the Evaluation Time for the Text Field), report generation takes a lot less (~65MB less) memory.

A few questions:

1. Is there any way to have each page's page number correctly calculated without using as much memory? Ideally I would like to have the report generation use constant memory

2. Is my assessment of where the memory consumption goes when delayed evaluation is used, correct? If so, are there any plans to reduce the amount of memory delayed actions use? What would this work involve?

Thanks a lot!

Cheers,
Anton

 

[yama818]

I don't know if this is a solution, but there is a setting to reduce memory consumption.

Virtualizers in JasperReports
https://community.jaspersoft.com/wiki/virtualizers-jasperreports

I hope this will be helpful to you.

 

[anton.mazkovoi_1]

Thanks a lot for your reply!

Virtualizers don't really help as they virtualise the final content, which in my case is about 2.5MB for the whole report. This is relatively small compared to the 65MB used to keep track of pages for delayed fill actions. I'd love to know if there is any way to reduce the amount of memory delayed fill actions use.

Depending on what's involved I would not mind giving that a go myself and then contributing back into the framework, but firstly wanted to understand if my understanding of the problem is correct, and how difficult this would be to implement (e.g. will this require major rework of the existing framework).

[lucianc]

It would be easier to discuss this by looking at a concrete case.  Do you have a self contained example to illustrate what you're describing?  If so, please attach it to a tracker so that we can run it and see what exactly is the memory used for and what can be done about it.

Regards,

Lucian

[anton.mazkovoi_1]

Hi Lucian,

Thanks for your reply!

We have a microservices architecture and the report pulls data from a number of services, so I do not have a readily shareable example.

I do have a hprof heap dump that shows the issue, which I am more than happy to share. Would that help?

The heap dump file is about 128MB. Is there a preferred place for me to upload it? If not, I can chuck it up somewhere for you to access.

Cheers,
Anton

 

[lucianc]

A heap dump would probably help.  But before uploading one, please be aware that heap dumps can contain sensitive information.

If it's not easy to provide the data to run the report, we could take a look at the report .jrxml(s), maybe we'll be able to reproduce the problem with some dummy data.  So attaching the report .jrxml would fine as a starting point.

[anton.mazkovoi_1]

Hi,

Please find the report jrxml files attached (as report_files.zip).

The culprit seems to be:

<textField evaluationTime="Master">

   <reportElement style="Footer Style" x="652" y="5" width="150" height="16" uuid="6b9c3cba-7edb-484c-b9f9-86b3e5effc0d"/>

   <textElement textAlignment="Right"/>

   <textFieldExpression><![CDATA["Page " + $V{MASTER_CURRENT_PAGE}]]></textFieldExpression>

</textField>

in ace_platform_main_report_book_footer_landscape.jrxml

The idea is to ensure the pages are numbers after the report's TOC is generated, so that each page's number corresponds exactly with its order in the report pdf file.

I am also attaching screenshots from the Heap Dump analysis that show DelayedFillActions holding onto about 61M of memory.

Without evaluationTime="Master" the amount of used memory is considerably smaller.

Is it a surprise that DelayedFillActions uses this much memory?

Thanks a lot for your help!

Cheers,
Anton

[anton.mazkovoi_1]

Hi Lucianc,

Wondering if you had a chance to have a look at this?

If not, would you be able to comment if having DelayedFillActions take up so much more memory (in my case ~61MB) than the actual report (in my case ~2.5MB) is expected behaviour?

Thanks a lot for your help!

Cheers,
Anton

 

[lucianc]

We're aware that elements with Master delayed evaluation do cause some memory do be retained during the report generation.  We haven't investigated your specific case to see if what we already know fully explains what you're describing, or if there's something that we're not aware of.

It would be better to log an issue in the trackers with the information you provided here, we'll take a look at it when possible and see if there's anything that can be done to reduce the memory usage.

Regards,

Lucian