nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Out of Memory java heap error

Jim Phelps

I'm getting an out of memory error when volume testing report generation of PDF's. Please advise if there's a known reason(s) for this. Many Thanks, Jim

Find more posts tagged with

Comments

Jim Phelps

I should add that we are sending pojo's to the template and using java script to read the data for a table used in the report.

Jim Phelps

We are creating reports by sending pojo's to a BIRT template that uses Java Script to read the data and lists for loading objects used in tables on the template. When volume testing the speed of invoice creation we are getting java heap out of memory exceptions after generating around 100. Please advise if you know of some potential causes for this. We are going to run JProfiler on the process to research what's happening. Many Thanks, Jim

mwilliams

What size is your heap space set at? Have you tried increasing it?

Yaytay

<blockquote class="ipsBlockquote" data-author="Jim Phelps" data-cid="120468" data-time="1379532889">We are creating reports by sending pojo's to a BIRT template that uses Java Script to read the data and lists for loading objects used in tables on the template.
</blockquote>I had cause to play about a bit with the script handlers in BIRT when writing my <a data-ipb='nomediaparse' class="bbc_url" href='https://bitbucket.org/yaytay/spudsoft-birt-dynamic-columns'>Dynamic Columns plugin</a> and I found that the performance was really poor (i.e. thousands of times worse than without he script in some circumstances, for trivial scripts).
I can't say that this ever led to memory problems for me, but I do run with a large heap.
The fix was to change to use a Java Scripted DataSet Event Handler, which is much more efficient and avoids starting the Javascript engine.

Obviously your problem isn't the same as mine, but switching to a Java Event Handler might solve your issues too.
Java Event Handlers are really easy to write (easier than Javascript because you can have more help from your IDE), bu they are a bit of a pain to deploy.

Jim

Jim Phelps

JProfiiler indicated that the DataSetScriptExecutor was hogging around 140 mB. Our contractor found that our version of BIRT 2.6.2 has a known memory leak. We are looking at going to 2.3 which reportedly does not have the memory leak. Let me know if you have run into this. We have templates ready for production and hopefully won't have to rewrite them with this Free product that hopefully is worth more than it's cost.

Yaytay

Going back? Crikey. I'd love to suggest that moving up would solve your problems but, despite it giving many benefits, I suspect it wouldn't.

I'm not surprised that he leak is in that area, and switching to a Java Event Handler would avoid it.
Did you find a logged bug for it?

Jim

CBR

Your contractor is totally right. There is a known memory leak in BIRT 2.6.2 that is exactly located in the DataSetScriptExecutor.class (see: <a data-ipb='nomediaparse' href='https://bugs.eclipse.org/bugs/show_bug.cgi?id=348845)'>https://bugs.eclipse.org/bugs/show_bug.cgi?id=348845)</a>The bug has been fixed in 3.7.0 accoring to eclipse bugtracker. If you have to downgrade to 2.3 you would have to recreate all reports that were created in a BIRT Designer version >2.3Upgrading would not be that problematic because of backward compatibility (nevertheless one would never just upgrade/downgrade without tests and some initial bug reasearch...just search bugs.eclipse.org for bugs that were created for BIRT 3.7.0) @YaytayRegarding the performance:I have also seen that for other Rhino script parts besides datasets as well. In some cases it even made sense to use the corresponding java objects instead of the rhino script functions/objects because performance was that much better using the real and correct Java object.Is this also what you have seen? Or was your test related to the dataset specific scripts only?