[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[
https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15481100#comment-15481100
]
Andrew Garcia commented on GROOVY-7683:
---
Any idea when the expected 2.4.8 release date is?
> Memory leak when using Groovy as JSR-223 scripting language.
>
>
> Key: GROOVY-7683
> URL: https://issues.apache.org/jira/browse/GROOVY-7683
> Project: Groovy
> Issue Type: Bug
> Components: GroovyScriptEngine
>Affects Versions: 2.4.5
> Environment: OS: tested on Mac OS X El Capitan and Windows 10.
> JVM: tested on 1.8.0_60 and 1.8.0_65.
>Reporter: Arkadiusz Gasinski
>Assignee: John Wagenleitner
> Labels: jsr-223
> Fix For: 2.4.8
>
> Attachments:
> 0001-GROOVY-7683-replace-hard-reference-from-ClassInfo-to.patch, Screen Shot
> 2016-08-16 at 10.53.04 PM.png
>
>
> We have a Java EE 7 web application in production that when handling single
> HTTP request can load and execute up to several Groovy scripts using the
> jsr-223 API. This application is deployed to GlassFish 4.1 server cluster
> with 4 instances, each having 8 GB of RAM available (Xmx=8g). We have to
> restart them every couple of days (3-4), because of leaking memory. After
> analyzing a couple of heap dumps, our main suspect is Groovy with its
> MetaMethodIndex$Entry class (the below table shows the top object from one of
> the heap dumps).
> ||Class Name||Objects||Shallow Heap||Retained Heap||
> |MetaMethodIndex$Entry| 3 360 001 | 188 160 056 | >= 305 408 024
> To confirm our suspicions, I created simple Maven project with a single test
> case. The project is available on
> [GitHub|https://github.com/jigga/groovy-jsr223-leak]. The test case executes
> 10 different scripts (minimal differences) obtained from a single template
> 2 times in 64 worker threads (the main thread is put to sleep for 10
> seconds before starting worker threads, so that one can attach JVisualVM to
> the test process). After all threads are done, System.gc() is called to
> provoke full GC. Attaching to the process in which tests are run with
> JVisualVM reveals that the memory is not reclaimed.
> To run the test in your local environment, simply clone the
> [GitHub|https://github.com/jigga/groovy-jsr223-leak] project and run:
> {code}
> mvn test
> {code}
> The same test can be run with the *-Dlanguage=javascript* system option,
> which switches ScriptEngine from Groovy to Nashorn and uses slightly modified
> script template (only syntactical differences).
> {code}
> mvn -Dlanguage=javascript test
> {code}
> Running the test case using built-in Nashorn engine reveals no problems - all
> allocated memory is reclaimed after full GC.
> I know that the test case is run in Java SE environment, but I guess that it
> clearly reflects the issue. If it's not enough, I can create an arquillian
> test case.
> This may be a possible duplicate of
> [GROOVY-7109|https://issues.apache.org/jira/browse/GROOVY-7109].
> Any workarounds for this issue would be greatly appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[
https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15449142#comment-15449142
]
Andrew Garcia commented on GROOVY-7683:
---
Also linking because I added a walkthrough on how I got that JDK to play nice
with my grails project.
> Memory leak when using Groovy as JSR-223 scripting language.
>
>
> Key: GROOVY-7683
> URL: https://issues.apache.org/jira/browse/GROOVY-7683
> Project: Groovy
> Issue Type: Bug
> Components: GroovyScriptEngine
>Affects Versions: 2.4.5
> Environment: OS: tested on Mac OS X El Capitan and Windows 10.
> JVM: tested on 1.8.0_60 and 1.8.0_65.
>Reporter: Arkadiusz Gasinski
> Labels: jsr-223
> Attachments:
> 0001-GROOVY-7683-replace-hard-reference-from-ClassInfo-to.patch, Screen Shot
> 2016-08-16 at 10.53.04 PM.png
>
>
> We have a Java EE 7 web application in production that when handling single
> HTTP request can load and execute up to several Groovy scripts using the
> jsr-223 API. This application is deployed to GlassFish 4.1 server cluster
> with 4 instances, each having 8 GB of RAM available (Xmx=8g). We have to
> restart them every couple of days (3-4), because of leaking memory. After
> analyzing a couple of heap dumps, our main suspect is Groovy with its
> MetaMethodIndex$Entry class (the below table shows the top object from one of
> the heap dumps).
> ||Class Name||Objects||Shallow Heap||Retained Heap||
> |MetaMethodIndex$Entry| 3 360 001 | 188 160 056 | >= 305 408 024
> To confirm our suspicions, I created simple Maven project with a single test
> case. The project is available on
> [GitHub|https://github.com/jigga/groovy-jsr223-leak]. The test case executes
> 10 different scripts (minimal differences) obtained from a single template
> 2 times in 64 worker threads (the main thread is put to sleep for 10
> seconds before starting worker threads, so that one can attach JVisualVM to
> the test process). After all threads are done, System.gc() is called to
> provoke full GC. Attaching to the process in which tests are run with
> JVisualVM reveals that the memory is not reclaimed.
> To run the test in your local environment, simply clone the
> [GitHub|https://github.com/jigga/groovy-jsr223-leak] project and run:
> {code}
> mvn test
> {code}
> The same test can be run with the *-Dlanguage=javascript* system option,
> which switches ScriptEngine from Groovy to Nashorn and uses slightly modified
> script template (only syntactical differences).
> {code}
> mvn -Dlanguage=javascript test
> {code}
> Running the test case using built-in Nashorn engine reveals no problems - all
> allocated memory is reclaimed after full GC.
> I know that the test case is run in Java SE environment, but I guess that it
> clearly reflects the issue. If it's not enough, I can create an arquillian
> test case.
> This may be a possible duplicate of
> [GROOVY-7109|https://issues.apache.org/jira/browse/GROOVY-7109].
> Any workarounds for this issue would be greatly appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[
https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Garcia updated GROOVY-7683:
--
Comment: was deleted
(was: Also linking because I added a walkthrough on how I got that JDK to play
nice with my grails project.)
> Memory leak when using Groovy as JSR-223 scripting language.
>
>
> Key: GROOVY-7683
> URL: https://issues.apache.org/jira/browse/GROOVY-7683
> Project: Groovy
> Issue Type: Bug
> Components: GroovyScriptEngine
>Affects Versions: 2.4.5
> Environment: OS: tested on Mac OS X El Capitan and Windows 10.
> JVM: tested on 1.8.0_60 and 1.8.0_65.
>Reporter: Arkadiusz Gasinski
> Labels: jsr-223
> Attachments:
> 0001-GROOVY-7683-replace-hard-reference-from-ClassInfo-to.patch, Screen Shot
> 2016-08-16 at 10.53.04 PM.png
>
>
> We have a Java EE 7 web application in production that when handling single
> HTTP request can load and execute up to several Groovy scripts using the
> jsr-223 API. This application is deployed to GlassFish 4.1 server cluster
> with 4 instances, each having 8 GB of RAM available (Xmx=8g). We have to
> restart them every couple of days (3-4), because of leaking memory. After
> analyzing a couple of heap dumps, our main suspect is Groovy with its
> MetaMethodIndex$Entry class (the below table shows the top object from one of
> the heap dumps).
> ||Class Name||Objects||Shallow Heap||Retained Heap||
> |MetaMethodIndex$Entry| 3 360 001 | 188 160 056 | >= 305 408 024
> To confirm our suspicions, I created simple Maven project with a single test
> case. The project is available on
> [GitHub|https://github.com/jigga/groovy-jsr223-leak]. The test case executes
> 10 different scripts (minimal differences) obtained from a single template
> 2 times in 64 worker threads (the main thread is put to sleep for 10
> seconds before starting worker threads, so that one can attach JVisualVM to
> the test process). After all threads are done, System.gc() is called to
> provoke full GC. Attaching to the process in which tests are run with
> JVisualVM reveals that the memory is not reclaimed.
> To run the test in your local environment, simply clone the
> [GitHub|https://github.com/jigga/groovy-jsr223-leak] project and run:
> {code}
> mvn test
> {code}
> The same test can be run with the *-Dlanguage=javascript* system option,
> which switches ScriptEngine from Groovy to Nashorn and uses slightly modified
> script template (only syntactical differences).
> {code}
> mvn -Dlanguage=javascript test
> {code}
> Running the test case using built-in Nashorn engine reveals no problems - all
> allocated memory is reclaimed after full GC.
> I know that the test case is run in Java SE environment, but I guess that it
> clearly reflects the issue. If it's not enough, I can create an arquillian
> test case.
> This may be a possible duplicate of
> [GROOVY-7109|https://issues.apache.org/jira/browse/GROOVY-7109].
> Any workarounds for this issue would be greatly appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GROOVY-7623) IBM Java (J9) ClassValue works correctly so should use it by default
[
https://issues.apache.org/jira/browse/GROOVY-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15449136#comment-15449136
]
Andrew Garcia edited comment on GROOVY-7623 at 8/30/16 2:19 PM:
For anyone who is attempting to use the IBM JDK 8 for a grails project, here is
how I did it in my development environment for a Grails 2.5.5 project. I'm
sure there is a lower common denominator of a solution but, this is what I did.
I'm currently deploying to Heroku in production and developing on Mac OSX so
it made things a little trickier since I didn't have a Linux environment handy
to unpack the .bin from IBM.
Once you've got the .tar.gz in hand, I had to untar it, remove jre/lib/xml.jar
since it's using old versions of xerces/xalan/etc classes and weren't playing
nice with my Grails 2.5.5 project. Then, I added the following files into
jre/lib/endorsed:
jaxp-api-1.4.2.jar, serializer-2.7.2.jar, xalan-2.7.2.jar,
xercesImpl-2.9.1.jar, xml-apis-1.3.04.jar
Now, there's a fun little piece of code in ClasspathConfigurer that likes to
force you to use a particular javax.xml.parsers.DocumentBuilderFactory if
Grails finds a xercesImpl dependency (transitive or not) in your BuildConfig.
And, ClasspathConfigurer gets invoked when using ./grailsw (which Heroku makes
use of). So, that's why I "had" to put xercesImpl in the endorsed lib instead
of just using the version in my project. I attempted to use the IBM JDK as it
was combined with Heroku's support for a .jdk-overlay directory but it wasn't
strong enough of an override.
{code:title=ClasspathConfigurer.java|borderStyle=solid}
protected void addDependenciesToURLs(Set excludes, List urls,
List runtimeDeps) throws MalformedURLException {
if (runtimeDeps == null) {
return;
}
for (File file : runtimeDeps) {
if (file == null ) {
continue;
}
if (file.getName().contains("xercesImpl")) {
// workaround for GRAILS-9708
System.setProperty("javax.xml.parsers.DocumentBuilderFactory","com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl");
}
if (excludes != null && !excludes.contains(file.getName())) {
URL url = file.toURI().toURL();
if (urls.contains(url)) continue;
urls.add(url);
excludes.add(file.getName());
}
}
}
{code}
In my BuildConfig.groovy I had to add setting the following dependencies:
{code}
runtime ('org.codehaus.groovy.modules.http-builder:http-builder:0.7.1')
{excludes 'xercesImpl'}
runtime "xalan:xalan:2.7.2"
runtime "com.fasterxml.woodstox:woodstox-core:5.0.3"
{code}
The xercesImpl exclusion I explained and the woodstox is because the xml.jar
IBM had included some streaming XML class files that needed replenishing.
Then..
After I re-tared up the IBM JDK with the xml.jar removed and my other jars
inserted I was able to start the Heroku server and get past the step of grailsw
that auto-generates the war file.
Then
I ran into the problem where IBM's JSSE loves to default to using TLS 1.0 and
my integration with Stripe was failing since that requires TLSv1.2 "or higher".
After some more headbanging I ran into this IBM support doc that was
satisfyingly infuriating. I was simultaneously pissed they made the choice not
to operate like every other JDK but at least they made it possible to play nice.
{quote}
Use the system property com.ibm.jsse2.overrideDefaultTLS to match the behavior
of SSLContext.getInstance("TLS") in the IBM SDK with the Oracle implementation.
com.ibm.jsse2.overrideDefaultTLS =true|false
{quote}
from [IBM
Support|http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/matchsslcontext_tls.html#matchsslcontext_tls]
After all of that and I'm still not seeing the classes get garbage collected.
I pray it's because I'm somehow misusing groovy.use.classvalue=true
!Screen Shot 2016-08-30 at 10.11.18 AM.png!
was (Author: gsandrew):
For anyone who is attempting to use the IBM JDK 8 for a grails project, here is
how I did it in my development environment for a Grails 2.5.5 project. I'm
sure there is a lower common denominator of a solution but, this is what I did.
I'm currently deploying to Heroku in production and developing on Mac OSX so
it made things a little trickier since I didn't have a Linux environment handy
to unpack the .bin from IBM.
Once you've got the .tar.gz in hand, I had to untar it, remove jre/lib/xml.jar
since it's using old versions of xerces/xalan/etc classes and weren't playing
nice with my Grails 2.5.5 project. Then, I added the following files into
jre/lib/endorsed:
jaxp-api-1.4.2.jar, serializer-2.7.2.jar, xalan-2.7.2.jar,
xercesImpl-2.9.1.jar,
[jira] [Comment Edited] (GROOVY-7623) IBM Java (J9) ClassValue works correctly so should use it by default
[
https://issues.apache.org/jira/browse/GROOVY-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15449136#comment-15449136
]
Andrew Garcia edited comment on GROOVY-7623 at 8/30/16 2:18 PM:
For anyone who is attempting to use the IBM JDK 8 for a grails project, here is
how I did it in my development environment for a Grails 2.5.5 project. I'm
sure there is a lower common denominator of a solution but, this is what I did.
I'm currently deploying to Heroku in production and developing on Mac OSX so
it made things a little trickier since I didn't have a Linux environment handy
to unpack the .bin from IBM.
Once you've got the .tar.gz in hand, I had to untar it, remove jre/lib/xml.jar
since it's using old versions of xerces/xalan/etc classes and weren't playing
nice with my Grails 2.5.5 project. Then, I added the following files into
jre/lib/endorsed:
jaxp-api-1.4.2.jar, serializer-2.7.2.jar, xalan-2.7.2.jar,
xercesImpl-2.9.1.jar, xml-apis-1.3.04.jar
Now, there's a fun little piece of code in ClasspathConfigurer that likes to
force you to use a particular javax.xml.parsers.DocumentBuilderFactory if
Grails finds a xercesImpl dependency (transitive or not) in your BuildConfig.
And, ClasspathConfigurer gets invoked when using ./grailsw (which Heroku makes
use of). So, that's why I "had" to put xercesImpl in the endorsed lib instead
of just using the version in my project. I attempted to use the IBM JDK as it
was combined with Heroku's support for a .jdk-overlay directory but it wasn't
strong enough of an override.
{code:title=ClasspathConfigurer.java|borderStyle=solid}
protected void addDependenciesToURLs(Set excludes, List urls,
List runtimeDeps) throws MalformedURLException {
if (runtimeDeps == null) {
return;
}
for (File file : runtimeDeps) {
if (file == null ) {
continue;
}
if (file.getName().contains("xercesImpl")) {
// workaround for GRAILS-9708
System.setProperty("javax.xml.parsers.DocumentBuilderFactory","com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl");
}
if (excludes != null && !excludes.contains(file.getName())) {
URL url = file.toURI().toURL();
if (urls.contains(url)) continue;
urls.add(url);
excludes.add(file.getName());
}
}
}
{code}
In my BuildConfig.groovy I had to add setting the following dependencies:
{code}
runtime ('org.codehaus.groovy.modules.http-builder:http-builder:0.7.1')
{excludes 'xercesImpl'}
runtime "xalan:xalan:2.7.2"
runtime "com.fasterxml.woodstox:woodstox-core:5.0.3"
{code}
The xercesImpl exclusion I explained and the woodstox is because the xml.jar
IBM had included some streaming XML class files that needed replenishing.
Then..
After I re-tared up the IBM JDK with the xml.jar removed and my other jars
inserted I was able to start the Heroku server and get past the step of grailsw
that auto-generates the war file.
Then
I ran into the problem where IBM's JSSE loves to default to using TLS 1.0 and
my integration with Stripe was failing since that requires TLSv1.2 "or higher".
After some more headbanging I ran into this IBM support doc that was
satisfyingly infuriating. I was simultaneously pissed they made the choice not
to operate like every other JDK but at least they made it possible to play nice.
{quote}
Use the system property com.ibm.jsse2.overrideDefaultTLS to match the behavior
of SSLContext.getInstance("TLS") in the IBM SDK with the Oracle implementation.
com.ibm.jsse2.overrideDefaultTLS =true|false
{quote}
from [IBM
Support|http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/matchsslcontext_tls.html#matchsslcontext_tls]
After all of that and I'm still not seeing the classes get garbage collected.
!Screen Shot 2016-08-30 at 10.11.18 AM.png!
was (Author: gsandrew):
For anyone who is attempting to use the IBM JDK 8 for a grails project, here is
how I did it in my development environment for a Grails 2.5.5 project. I'm
sure there is a lower common denominator of a solution but, this is what I did.
I'm currently deploying to Heroku in production and developing on Mac OSX so
it made things a little trickier since I didn't have a Linux environment handy
to unpack the .bin from IBM.
Once you've got the .tar.gz in hand, I had to untar it, remove jre/lib/xml.jar
since it's using old versions of xerces/xalan/etc classes and weren't playing
nice with my Grails 2.5.5 project. Then, I added the following files into
jre/lib/endorsed:
jaxp-api-1.4.2.jar, serializer-2.7.2.jar, xalan-2.7.2.jar,
xercesImpl-2.9.1.jar, xml-apis-1.3.04.jar
Now, there's a fun little piece of code in
[jira] [Updated] (GROOVY-7623) IBM Java (J9) ClassValue works correctly so should use it by default
[ https://issues.apache.org/jira/browse/GROOVY-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Garcia updated GROOVY-7623: -- Attachment: Screen Shot 2016-08-30 at 10.11.18 AM.png > IBM Java (J9) ClassValue works correctly so should use it by default > > > Key: GROOVY-7623 > URL: https://issues.apache.org/jira/browse/GROOVY-7623 > Project: Groovy > Issue Type: Bug >Affects Versions: 2.4.5 >Reporter: Craig >Assignee: Pascal Schumacher > Fix For: 2.4.6 > > Attachments: Screen Shot 2016-08-30 at 10.11.18 AM.png > > > GROOVY-7591 disabled the use of java.lang.ClassValue by default due to a bug > in OpenJDK: https://bugs.openjdk.java.net/browse/JDK-8136353 The result is > that GROOVY-6704 occurs on all versions of Java again. > The bug in OpenJDK does not impact IBM Java, so when running on IBM Java, > java.lang.ClassValue should be used by default. So at least users on IBM > Java will not experience GROOVY-6704. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GROOVY-7623) IBM Java (J9) ClassValue works correctly so should use it by default
[
https://issues.apache.org/jira/browse/GROOVY-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15449136#comment-15449136
]
Andrew Garcia commented on GROOVY-7623:
---
For anyone who is attempting to use the IBM JDK 8 for a grails project, here is
how I did it in my development environment for a Grails 2.5.5 project. I'm
sure there is a lower common denominator of a solution but, this is what I did.
I'm currently deploying to Heroku in production and developing on Mac OSX so
it made things a little trickier since I didn't have a Linux environment handy
to unpack the .bin from IBM.
Once you've got the .tar.gz in hand, I had to untar it, remove jre/lib/xml.jar
since it's using old versions of xerces/xalan/etc classes and weren't playing
nice with my Grails 2.5.5 project. Then, I added the following files into
jre/lib/endorsed:
jaxp-api-1.4.2.jar, serializer-2.7.2.jar, xalan-2.7.2.jar,
xercesImpl-2.9.1.jar, xml-apis-1.3.04.jar
Now, there's a fun little piece of code in ClasspathConfigurer that likes to
force you to use a particular javax.xml.parsers.DocumentBuilderFactory if
Grails finds a xercesImpl dependency (transitive or not) in your BuildConfig.
And, ClasspathConfigurer gets invoked when using ./grailsw (which Heroku makes
use of). So, that's why I "had" to put xercesImpl in the endorsed lib instead
of just using the version in my project. I attempted to use the IBM JDK as it
was combined with Heroku's support for a .jdk-overlay directory but it wasn't
strong enough of an override.
{code:title=ClasspathConfigurer.java|borderStyle=solid}
protected void addDependenciesToURLs(Set excludes, List urls,
List runtimeDeps) throws MalformedURLException {
if (runtimeDeps == null) {
return;
}
for (File file : runtimeDeps) {
if (file == null ) {
continue;
}
if (file.getName().contains("xercesImpl")) {
// workaround for GRAILS-9708
System.setProperty("javax.xml.parsers.DocumentBuilderFactory","com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl");
}
if (excludes != null && !excludes.contains(file.getName())) {
URL url = file.toURI().toURL();
if (urls.contains(url)) continue;
urls.add(url);
excludes.add(file.getName());
}
}
}
{code}
In my BuildConfig.groovy I had to add setting the following dependencies:
{code}
runtime ('org.codehaus.groovy.modules.http-builder:http-builder:0.7.1')
{excludes 'xercesImpl'}
runtime "xalan:xalan:2.7.2"
runtime "com.fasterxml.woodstox:woodstox-core:5.0.3"
{code}
The xercesImpl exclusion I explained and the woodstox is because the xml.jar
IBM had included some streaming XML class files that needed replenishing.
Then..
After I re-tared up the IBM JDK with the xml.jar removed and my other jars
inserted I was able to start the Heroku server and get past the step of grailsw
that auto-generates the war file.
Then
I ran into the problem where IBM's JSSE loves to default to using TLS 1.0 and
my integration with Stripe was failing since that requires TLSv1.2 "or higher".
After some more headbanging I ran into this IBM support doc that was
satisfyingly infuriating. I was simultaneously pissed they made the choice not
to operate like every other JDK but at least they made it possible to play nice.
{quote}
Use the system property com.ibm.jsse2.overrideDefaultTLS to match the behavior
of SSLContext.getInstance("TLS") in the IBM SDK with the Oracle implementation.
com.ibm.jsse2.overrideDefaultTLS =true|false
{quote}
from [IBM
Support|http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/matchsslcontext_tls.html#matchsslcontext_tls]
After all of that and I'm still not seeing the classes get garbage collected.
!http://imgur.com/a/be9JY!
> IBM Java (J9) ClassValue works correctly so should use it by default
>
>
> Key: GROOVY-7623
> URL: https://issues.apache.org/jira/browse/GROOVY-7623
> Project: Groovy
> Issue Type: Bug
>Affects Versions: 2.4.5
>Reporter: Craig
>Assignee: Pascal Schumacher
> Fix For: 2.4.6
>
> Attachments: Screen Shot 2016-08-30 at 10.11.18 AM.png
>
>
> GROOVY-7591 disabled the use of java.lang.ClassValue by default due to a bug
> in OpenJDK: https://bugs.openjdk.java.net/browse/JDK-8136353 The result is
> that GROOVY-6704 occurs on all versions of Java again.
> The bug in OpenJDK does not impact IBM Java, so when running on IBM Java,
> java.lang.ClassValue should be used by default. So at least users on IBM
> Java will not experience GROOVY-6704.
--
This
[jira] [Comment Edited] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[
https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15447782#comment-15447782
]
Andrew Garcia edited comment on GROOVY-7683 at 8/30/16 2:38 AM:
Linking to [Groovy-7623|https://issues.apache.org/jira/browse/GROOVY-7623] as
it claims to be a possible solution path to this memory leak issue.
was (Author: gsandrew):
Linking to[#Groovy-7623] as it claims to be a possible solution path to this
memory leak issue
> Memory leak when using Groovy as JSR-223 scripting language.
>
>
> Key: GROOVY-7683
> URL: https://issues.apache.org/jira/browse/GROOVY-7683
> Project: Groovy
> Issue Type: Bug
> Components: GroovyScriptEngine
>Affects Versions: 2.4.5
> Environment: OS: tested on Mac OS X El Capitan and Windows 10.
> JVM: tested on 1.8.0_60 and 1.8.0_65.
>Reporter: Arkadiusz Gasinski
> Labels: jsr-223
> Attachments:
> 0001-GROOVY-7683-replace-hard-reference-from-ClassInfo-to.patch, Screen Shot
> 2016-08-16 at 10.53.04 PM.png
>
>
> We have a Java EE 7 web application in production that when handling single
> HTTP request can load and execute up to several Groovy scripts using the
> jsr-223 API. This application is deployed to GlassFish 4.1 server cluster
> with 4 instances, each having 8 GB of RAM available (Xmx=8g). We have to
> restart them every couple of days (3-4), because of leaking memory. After
> analyzing a couple of heap dumps, our main suspect is Groovy with its
> MetaMethodIndex$Entry class (the below table shows the top object from one of
> the heap dumps).
> ||Class Name||Objects||Shallow Heap||Retained Heap||
> |MetaMethodIndex$Entry| 3 360 001 | 188 160 056 | >= 305 408 024
> To confirm our suspicions, I created simple Maven project with a single test
> case. The project is available on
> [GitHub|https://github.com/jigga/groovy-jsr223-leak]. The test case executes
> 10 different scripts (minimal differences) obtained from a single template
> 2 times in 64 worker threads (the main thread is put to sleep for 10
> seconds before starting worker threads, so that one can attach JVisualVM to
> the test process). After all threads are done, System.gc() is called to
> provoke full GC. Attaching to the process in which tests are run with
> JVisualVM reveals that the memory is not reclaimed.
> To run the test in your local environment, simply clone the
> [GitHub|https://github.com/jigga/groovy-jsr223-leak] project and run:
> {code}
> mvn test
> {code}
> The same test can be run with the *-Dlanguage=javascript* system option,
> which switches ScriptEngine from Groovy to Nashorn and uses slightly modified
> script template (only syntactical differences).
> {code}
> mvn -Dlanguage=javascript test
> {code}
> Running the test case using built-in Nashorn engine reveals no problems - all
> allocated memory is reclaimed after full GC.
> I know that the test case is run in Java SE environment, but I guess that it
> clearly reflects the issue. If it's not enough, I can create an arquillian
> test case.
> This may be a possible duplicate of
> [GROOVY-7109|https://issues.apache.org/jira/browse/GROOVY-7109].
> Any workarounds for this issue would be greatly appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[
https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15447782#comment-15447782
]
Andrew Garcia edited comment on GROOVY-7683 at 8/30/16 2:38 AM:
Linking to[#Groovy-7623] as it claims to be a possible solution path to this
memory leak issue
was (Author: gsandrew):
Linking to https://issues.apache.org/jira/browse/GROOVY-7623 as it claims to be
a possible solution path to this memory leak issue
> Memory leak when using Groovy as JSR-223 scripting language.
>
>
> Key: GROOVY-7683
> URL: https://issues.apache.org/jira/browse/GROOVY-7683
> Project: Groovy
> Issue Type: Bug
> Components: GroovyScriptEngine
>Affects Versions: 2.4.5
> Environment: OS: tested on Mac OS X El Capitan and Windows 10.
> JVM: tested on 1.8.0_60 and 1.8.0_65.
>Reporter: Arkadiusz Gasinski
> Labels: jsr-223
> Attachments:
> 0001-GROOVY-7683-replace-hard-reference-from-ClassInfo-to.patch, Screen Shot
> 2016-08-16 at 10.53.04 PM.png
>
>
> We have a Java EE 7 web application in production that when handling single
> HTTP request can load and execute up to several Groovy scripts using the
> jsr-223 API. This application is deployed to GlassFish 4.1 server cluster
> with 4 instances, each having 8 GB of RAM available (Xmx=8g). We have to
> restart them every couple of days (3-4), because of leaking memory. After
> analyzing a couple of heap dumps, our main suspect is Groovy with its
> MetaMethodIndex$Entry class (the below table shows the top object from one of
> the heap dumps).
> ||Class Name||Objects||Shallow Heap||Retained Heap||
> |MetaMethodIndex$Entry| 3 360 001 | 188 160 056 | >= 305 408 024
> To confirm our suspicions, I created simple Maven project with a single test
> case. The project is available on
> [GitHub|https://github.com/jigga/groovy-jsr223-leak]. The test case executes
> 10 different scripts (minimal differences) obtained from a single template
> 2 times in 64 worker threads (the main thread is put to sleep for 10
> seconds before starting worker threads, so that one can attach JVisualVM to
> the test process). After all threads are done, System.gc() is called to
> provoke full GC. Attaching to the process in which tests are run with
> JVisualVM reveals that the memory is not reclaimed.
> To run the test in your local environment, simply clone the
> [GitHub|https://github.com/jigga/groovy-jsr223-leak] project and run:
> {code}
> mvn test
> {code}
> The same test can be run with the *-Dlanguage=javascript* system option,
> which switches ScriptEngine from Groovy to Nashorn and uses slightly modified
> script template (only syntactical differences).
> {code}
> mvn -Dlanguage=javascript test
> {code}
> Running the test case using built-in Nashorn engine reveals no problems - all
> allocated memory is reclaimed after full GC.
> I know that the test case is run in Java SE environment, but I guess that it
> clearly reflects the issue. If it's not enough, I can create an arquillian
> test case.
> This may be a possible duplicate of
> [GROOVY-7109|https://issues.apache.org/jira/browse/GROOVY-7109].
> Any workarounds for this issue would be greatly appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[
https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15447782#comment-15447782
]
Andrew Garcia edited comment on GROOVY-7683 at 8/30/16 2:37 AM:
Linking to https://issues.apache.org/jira/browse/GROOVY-7623 as it claims to be
a possible solution path to this memory leak issue
was (Author: gsandrew):
Linking to Groovy-7623 as it claims to be a possible solution path to this
memory leak issue
> Memory leak when using Groovy as JSR-223 scripting language.
>
>
> Key: GROOVY-7683
> URL: https://issues.apache.org/jira/browse/GROOVY-7683
> Project: Groovy
> Issue Type: Bug
> Components: GroovyScriptEngine
>Affects Versions: 2.4.5
> Environment: OS: tested on Mac OS X El Capitan and Windows 10.
> JVM: tested on 1.8.0_60 and 1.8.0_65.
>Reporter: Arkadiusz Gasinski
> Labels: jsr-223
> Attachments:
> 0001-GROOVY-7683-replace-hard-reference-from-ClassInfo-to.patch, Screen Shot
> 2016-08-16 at 10.53.04 PM.png
>
>
> We have a Java EE 7 web application in production that when handling single
> HTTP request can load and execute up to several Groovy scripts using the
> jsr-223 API. This application is deployed to GlassFish 4.1 server cluster
> with 4 instances, each having 8 GB of RAM available (Xmx=8g). We have to
> restart them every couple of days (3-4), because of leaking memory. After
> analyzing a couple of heap dumps, our main suspect is Groovy with its
> MetaMethodIndex$Entry class (the below table shows the top object from one of
> the heap dumps).
> ||Class Name||Objects||Shallow Heap||Retained Heap||
> |MetaMethodIndex$Entry| 3 360 001 | 188 160 056 | >= 305 408 024
> To confirm our suspicions, I created simple Maven project with a single test
> case. The project is available on
> [GitHub|https://github.com/jigga/groovy-jsr223-leak]. The test case executes
> 10 different scripts (minimal differences) obtained from a single template
> 2 times in 64 worker threads (the main thread is put to sleep for 10
> seconds before starting worker threads, so that one can attach JVisualVM to
> the test process). After all threads are done, System.gc() is called to
> provoke full GC. Attaching to the process in which tests are run with
> JVisualVM reveals that the memory is not reclaimed.
> To run the test in your local environment, simply clone the
> [GitHub|https://github.com/jigga/groovy-jsr223-leak] project and run:
> {code}
> mvn test
> {code}
> The same test can be run with the *-Dlanguage=javascript* system option,
> which switches ScriptEngine from Groovy to Nashorn and uses slightly modified
> script template (only syntactical differences).
> {code}
> mvn -Dlanguage=javascript test
> {code}
> Running the test case using built-in Nashorn engine reveals no problems - all
> allocated memory is reclaimed after full GC.
> I know that the test case is run in Java SE environment, but I guess that it
> clearly reflects the issue. If it's not enough, I can create an arquillian
> test case.
> This may be a possible duplicate of
> [GROOVY-7109|https://issues.apache.org/jira/browse/GROOVY-7109].
> Any workarounds for this issue would be greatly appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7683) Memory leak when using Groovy as JSR-223 scripting language.
[
https://issues.apache.org/jira/browse/GROOVY-7683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15447782#comment-15447782
]
Andrew Garcia commented on GROOVY-7683:
---
Linking to Groovy-7623 as it claims to be a possible solution path to this
memory leak issue
> Memory leak when using Groovy as JSR-223 scripting language.
>
>
> Key: GROOVY-7683
> URL: https://issues.apache.org/jira/browse/GROOVY-7683
> Project: Groovy
> Issue Type: Bug
> Components: GroovyScriptEngine
>Affects Versions: 2.4.5
> Environment: OS: tested on Mac OS X El Capitan and Windows 10.
> JVM: tested on 1.8.0_60 and 1.8.0_65.
>Reporter: Arkadiusz Gasinski
> Labels: jsr-223
> Attachments:
> 0001-GROOVY-7683-replace-hard-reference-from-ClassInfo-to.patch, Screen Shot
> 2016-08-16 at 10.53.04 PM.png
>
>
> We have a Java EE 7 web application in production that when handling single
> HTTP request can load and execute up to several Groovy scripts using the
> jsr-223 API. This application is deployed to GlassFish 4.1 server cluster
> with 4 instances, each having 8 GB of RAM available (Xmx=8g). We have to
> restart them every couple of days (3-4), because of leaking memory. After
> analyzing a couple of heap dumps, our main suspect is Groovy with its
> MetaMethodIndex$Entry class (the below table shows the top object from one of
> the heap dumps).
> ||Class Name||Objects||Shallow Heap||Retained Heap||
> |MetaMethodIndex$Entry| 3 360 001 | 188 160 056 | >= 305 408 024
> To confirm our suspicions, I created simple Maven project with a single test
> case. The project is available on
> [GitHub|https://github.com/jigga/groovy-jsr223-leak]. The test case executes
> 10 different scripts (minimal differences) obtained from a single template
> 2 times in 64 worker threads (the main thread is put to sleep for 10
> seconds before starting worker threads, so that one can attach JVisualVM to
> the test process). After all threads are done, System.gc() is called to
> provoke full GC. Attaching to the process in which tests are run with
> JVisualVM reveals that the memory is not reclaimed.
> To run the test in your local environment, simply clone the
> [GitHub|https://github.com/jigga/groovy-jsr223-leak] project and run:
> {code}
> mvn test
> {code}
> The same test can be run with the *-Dlanguage=javascript* system option,
> which switches ScriptEngine from Groovy to Nashorn and uses slightly modified
> script template (only syntactical differences).
> {code}
> mvn -Dlanguage=javascript test
> {code}
> Running the test case using built-in Nashorn engine reveals no problems - all
> allocated memory is reclaimed after full GC.
> I know that the test case is run in Java SE environment, but I guess that it
> clearly reflects the issue. If it's not enough, I can create an arquillian
> test case.
> This may be a possible duplicate of
> [GROOVY-7109|https://issues.apache.org/jira/browse/GROOVY-7109].
> Any workarounds for this issue would be greatly appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
