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

Hi, Please find the report jrxml files attached (as report_files.zip). The culprit seems to be: 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

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

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).

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