Birt Viewer 3.7.2_RC1 PermGen problem

Hello Experts, 
 
My Birt reports are deployed using the WebViewerExample (Birt runtime 3.7.2_RC1) on Tomcat 7.0.23 on Linux (RHEL) server. 
 
Every time a report is accessed, the PermGen spikes by 2-6 MB (varies for different reports). This increase is in just showing the Parameter input box to the user. On generating the report, there is a further increase of 2-5 MB in the PermGen usage. 
 
I have read that this is related to js.jar (Rhino) but am not sure. 
 
I am running with a PermGen limit of 3GB, but that is just delaying the inevitable OutOfMemory. 
Also, on my other server I don't have so much RAM so I am running with 1.2GB MaxPermGen and am forced to stop and start Tomcat everyday, even then if ~100 reports are generated intra-day, the jvm stops working with OOM errors which looks rather ugly because Tomcat won't even stop and the process has to be killed. 
 
Please advise how this can be reduced/rectified. If it's related to js.jar, then can you give some option to decide if I want to make the javascript compiled/interpreted. Interpreted js might be a bit slower, but is still better than going belly-up. 
 
Thanks 
-Sebastian

Find more posts tagged with

Comments

CBR

Hi,

did you already file a bug describing the problem? That would be a great opportunity to make sure that this bug is fixed in the final release.

The RC is only a release candidate, so you shouldn't use it in a production environment because of the possibility to encounter ciritical bugs.
Concerning your javascript question: BIRT is using the Rhino under the hood. It is not possible to compile all rhino in all your report to java and to let it be picked up by BIRT at runtime (because you can't tell BIRT to not use the rhino interpreter on your scripts.

s_^_s

<blockquote class='ipsBlockquote' data-author="'cbrell'" data-cid="94793" data-time="1328010979" data-date="31 January 2012 - 04:56 AM">
Hi, 
 
did you already file a bug describing the problem? ... </blockquote>
Hi Brell, 
 
This problem has been present in past versions. 
I was earlier on BIRT 2.6.x version and the PermGen increase was twice as much. 
I read that this is better in 3.7.1 so tried to use that. Turned out that WebViewerExample with BIRT runtime 3.7.1 (using connection profile datasource) keeps giving -'Unable to determine the default workspace location' error. The org.eclipse.datatools_workspacepath was set (as per the migration guide) yet I kept getting this error. 
Linda then made some changes in nightly build of DTP 1.9.2 RC2 (which can be used only with BIRT 3.7.2 RC1), so I am using 3.7.2. 
 
Anyhow, I am not sure that Rhino js.jar is the culprit, but there is definitely something which keeps adding to PermGen space. 
I have created a new <a class='bbc_url' href='https://bugs.eclipse.org/bugs/show_bug.cgi?id=370208'>Bug 370208</a> 
 
It would be good if your team can give some solution/workaround, even if that makes the reports a bit slower. Even with 2GB PermGen size (which is exceptionally high) the tomcat will crash after just 200-300 or so reports being viewed.

CBR

Hi,

to be honest i m not part of the dev team or even part of actuate.

You are right, there have been some memory leaks in BIRT 2.6.x that were related to rhino. The memory leak was caused by the scripted data source. This issue has been fixed in BIRT 3.7.0 and is not present in 3.7.1
Perhaps the same issue reappeared in 3.7.2 but i m not sure.
I agree, the issue you are seeing would prevent me from using 3.7.2 in a production environment too.