8

On our Wildfly 10 applicationserver we are using groovy for jasperreports and other similiar systems. After some time the jvm (java 8) gets an "Out of Memory: metaspace" error. The same issue happens on some older jboss 4 servers with permgen (java 6). We upgraded jasperreports from 3.7.2 to 6.3.1 and the problem still exists. The size of permgen/metaspace is big enough (Max 512 MB).

Our other applications that do not use jasperreports and groovy do not have this problem.

After some research i recognized that this is possibly a memory leak in a classloader (stackoverflow question). It seems that the gc does not unload classes generated from groovy.

On jaspersoft documentation they write, that u should set -XX:+UseConcMarkSweepGC and -XX:+CMSClassUnloadingEnabled as VM Parameter to enable class unloading.

So we changed it but the problem still exists. Does Java 8 still support these Parameters? If not is there any other solution. Currently we have to restart the server every night to avoid this problem.

Community
  • 1
  • 1
Hauke Kern
  • 91
  • 6
  • 2
    Have you tried getting a heap dump for the app? It might provide some insight into what is being allocated. If you look for a big collection generated classes, you might be able to find where they're being allocated. – Bruce Hamilton Oct 15 '16 at 12:29
  • 2
    You most likely do have a classloader leak. If you've got a good test ENV where you can reproduce the issue try running jmap -clstats on the box. It will cause the app to hang and takes a few minutes to run(10 or so in my app) but it gives you a full list of class loaders and their state. You'll most likely see a high volume of dead loads of type: "sun/reflect/DelegatingClassLoader" and "org/codehaus/groovy/runtime/callsite/CallSiteClassLoader" – Durandal Oct 15 '16 at 15:14
  • 2
    I would look at the classes which are being retained via a heap dump. This is the most likely cause of your memory leak. 0.5 GB should be big enough but it's not huge. If you make it 4 GB could you run for a week between restarts? – Peter Lawrey Oct 16 '16 at 10:34
  • 1
    Depends on the usage. Most of the times we can run it for 2 days without restarting, so 4GB should work for a week. Next week i will change metaspace to max 4GB and take a heap dump after 2 or 3 days. Thanks for the help so far, i will post my results when i have analyzed the heap dump. – Hauke Kern Oct 16 '16 at 12:40
  • @HaukeKern: What were your findings? – blubb Apr 12 '18 at 10:43
  • 1
    As Durandal mentioned mentioned, there where a lot of "sun/reflect/DelegatingClassLoader" and "org/codehaus/groovy/runtime/callsite/CallSiteClassLoader" entries in the heap dump. It seems that groovy has some memoryleak issues. We changed the script enginge from groovy to java for jasper reports and javascript for our other systems. This solved the Problem. Thanks for the help. – Hauke Kern Aug 01 '18 at 08:21
  • @Hauke How did you make script engine change from groovy to Java? We are also facing similar issue in our app. We do use dynamic reports a wrapper on top of jasper reports in grails app. – user1071671 Apr 18 '20 at 20:39
  • @user1071671 We dont use dynamic reports. We use plain jasper and create .jrxml/.jasper templates. In those templates we can chose the script language. – Hauke Kern Aug 30 '20 at 14:57
  • 1
    I also has an issue of OOM metaspace with groovy/jasper. In my case, issue is solved by change from groovy to java for expression and switching from compiling .jrxml in java code to loading a pre-compiled .jasper file. – Radit Panjapiyakul Apr 24 '21 at 03:43

1 Answers1

0

As Durandal mentioned mentioned in the comments of the question, there where a lot of "sun/reflect/DelegatingClassLoader" and "org/codehaus/groovy/runtime/callsite/CallSiteClassLoader" entries in the heap dump. It seems that groovy has some memoryleak issues. We changed the script enginge from groovy to java for jasper reports and javascript for our other systems. This solved the Problem. Thanks for the help.

Hauke Kern
  • 91
  • 6