Groovy runner seems to be causing class loader leaks

Description

*This issue has moved*

This issue has been moved permanently to Adaptavist's Product Support JIRA instance.

All existing users of this instance should have the same username on our Product Support instance. However, you will very likely need to click on the
Can't access your account link in order to reset to a new password.

I got groovy service which runs every 15 minutes. Over the time Perm Gen memory pool decreases. I run simple memory analysis and it looks like those groovy classes are never unloaded (Please find attached screenshots)

Environment

Base URL http://jiraweb
System Date Wednesday, 29 Sep 2010
System Time 12:21:32 -0500
Current Working Directory /apps/jira/atlassian-jira-enterprise-4.1.1-standalone/bin
Java Version 1.6.0_20
Java Vendor Sun Microsystems Inc.
JVM Version 1.0
JVM Vendor Sun Microsystems Inc.
JVM Implementation Version 16.3-b01
Java Runtime Java(TM) SE Runtime Environment
Java VM Java HotSpot(TM) 64-Bit Server VM
User Name tlsdpsql
User Timezone America/Chicago
User Locale English (United States)
System Encoding UTF-8
Operating System Linux 2.6.18-164.6.1.el5
OS Architecture amd64
Application Server Container Apache Tomcat/6.0.20
Database type postgres72
Database JNDI address java:comp/env/jdbc/JiraDS
Database URL jdbcostgresql://127.0.0.1:3307/jiraTitan04DB
Database version 8.4.3
Database driver PostgreSQL Native Driver PostgreSQL 8.4 JDBC4 (build 701)
External user management OFF
Crowd integration OFF
JVM Input Arguments -Djava.util.logging.config.file=/apps/jira/atlassian-jira-enterprise-4.1.1-standalone/conf/logging.properties -XX:MaxPermSize=1024m -Xms8G -Xmx8G -Djava.awt.headless=true -Datlassian.standalone=JIRA -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true -Dmail.mime.decodeparameters=true -XX:SurvivorRatio=6 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/apps/jira/atlassian-jira-enterprise-4.1.1-standalone/endorsed -Dcatalina.base=/apps/jira/atlassian-jira-enterprise-4.1.1-standalone -Dcatalina.home=/apps/jira/atlassian-jira-enterprise-4.1.1-standalone -Djava.io.tmpdir=/apps/jira/atlassian-jira-enterprise-4.1.1-standalone/temp
Modified Files [Installation Type: Standalone] jira-application.properties, entityengine.xml, osuser.xml
Removed Files [Installation Type: Standalone] There have been no removed files

Activity

Show:
Jamie Echlin
October 13, 2010, 4:28 PM

Can you try the version attached to this issue... it will cache classes generated from scripts, unless/until the script changes.

Jamie Echlin
October 13, 2010, 6:57 AM

Like I say I don't think this plugin is the issue. Can you reproduce this in a non-production system? If so please run it with the jvm args below, I don't think they will have impact on performance. may fix your issue but I don't see why you're even having the issue...

Lukasz Smoron
October 13, 2010, 6:50 AM

Actually I were running out of permgen.
I set it so high to allow jira instance run for 2 weeks w/o restarting.

Thanks
Luke

Jamie Echlin
October 13, 2010, 6:17 AM

Hi... I'm resolving this as "not a bug". Please open if you disagree.

The issue is that you have set your permgen very high, so the GC has no reason to unload the generated groovy classes, hence the classloader has 000s of generated classes. I don't think you actually said that you were running out of permgen space, and I doubt that is happening. I manage jira instances that have groovy services, and lots of groovy workflow functions... if this plugin was causing OoMs on permgen I would have seen it by now.

If you set your permgen to a more reasonable amount, and add -XX:+TraceClassLoading -XX:+TraceClassUnloading, you will see that when necessary the generated classes do get unloaded.

I used the following little test to verify this, with the two jvm opts above:

It may be better if I used a component plugin type to hang on to the ScriptEngineManager, which would give better performance, but that's another issue.

cheers, jamie

Brad Svee
October 12, 2010, 12:50 PM

I think that there might be a pretty big memory leak in the Main GroovyRunner.java execution "run" method. The code requests a BufferedReader to read the script file into the Script Engine, however no where in the try catch or finally does the code explicitly try to close the FileInputStream, the inputStreamReader, or the bufferedReader. We've been experiencing a complete system dead-lock with no errors or logs after a bunch of random script executions and I suspect that this might be the culprit.

Fixed
Your pinned fields
Click on the next to a field label to start pinning.

Assignee

Jamie Echlin

Reporter

Lukasz Smoron

Internal Complexity

Unknown

Internal Value

Unknown