[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=15527902#comment-15527902
]
John Wagenleitner commented on GROOVY-7683:
---
Not sure, but there's been some talk about it on the dev mailing list which is
usually a sign that it's not too far off.
> 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-7948) tab completion for static imports in groovysh does not work
[
https://issues.apache.org/jira/browse/GROOVY-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15527885#comment-15527885
]
John Wagenleitner commented on GROOVY-7948:
---
Thanks for reporting the issue, a pull request would be great.
> tab completion for static imports in groovysh does not work
> ---
>
> Key: GROOVY-7948
> URL: https://issues.apache.org/jira/browse/GROOVY-7948
> Project: Groovy
> Issue Type: Bug
> Components: Groovysh
>Affects Versions: 2.4.7
>Reporter: Abraham Grief
>
> Currently, if I run groovysh, and enter the following:
> {noformat}
> class MyMath {
> static int square(int x) {return x*x}
> }
> import static MyMath.*
> {noformat}
> Then enter {noformat}sq{noformat} followed by hitting the Tab key, groovysh
> does not provided any possible auto-completions.
> Instead, hitting the Tab key should auto-complete to the square method in
> MyMath.
> I fixed this already in my local groovy installation and can submit it as a
> pull request if that helps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GROOVY-7946) StreamingJsonBuilder should support writable values
[
https://issues.apache.org/jira/browse/GROOVY-7946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wagenleitner resolved GROOVY-7946.
---
Resolution: Fixed
Fix Version/s: 2.4.8
PR merged, thanks.
> StreamingJsonBuilder should support writable values
> ---
>
> Key: GROOVY-7946
> URL: https://issues.apache.org/jira/browse/GROOVY-7946
> Project: Groovy
> Issue Type: Improvement
>Affects Versions: 2.4.7
>Reporter: Graeme Rocher
> Fix For: 2.4.8
>
>
> In order to compose logic with StreamingJsonBuilder it is often desirable to
> split up the code into parts to make it more maintainable. For example with
> Grails' JSON views you may have several different templates that make up the
> entire JSON response.
> In order to support this we had to fork StreamingJsonBuilder and add the
> capability to pass a Writable as a value. The reason is, otherwise you have
> to buffer in memory an entire string for child template. For example now you
> would have to do something like this:
> {code}
> new StringWriter().with { w ->
> def builder = new StreamingJsonBuilder(w)
> def sw = new StringWriter()
>new StreamingJsonBuilder(sw).call {
> sectionId "world"
> }
> builder.response {
> status "ok"
> results sw.toString()
> }
> }
> {code}
> Which is inefficient and eliminates the memory benefits of streaming. Ideally
> you want to do this:
> {code}
> new StringWriter().with { w ->
> def builder = new StreamingJsonBuilder(w)
> def writable = new Writable() {
> @Override
> Writer writeTo(Writer writer) throws IOException {
> new StreamingJsonBuilder(writer).call {
> sectionId "world"
> }
> return writer
> }
> }
> builder.response {
> status "ok"
> results writable
> }
> }
> {code}
> Which allows you to continue streaming for child attributes of a JSON
> document.
> I have a pull request incoming for this improvement
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7946) StreamingJsonBuilder should support writable values
[
https://issues.apache.org/jira/browse/GROOVY-7946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15527866#comment-15527866
]
ASF GitHub Bot commented on GROOVY-7946:
Github user asfgit closed the pull request at:
https://github.com/apache/groovy/pull/429
> StreamingJsonBuilder should support writable values
> ---
>
> Key: GROOVY-7946
> URL: https://issues.apache.org/jira/browse/GROOVY-7946
> Project: Groovy
> Issue Type: Improvement
>Affects Versions: 2.4.7
>Reporter: Graeme Rocher
>
> In order to compose logic with StreamingJsonBuilder it is often desirable to
> split up the code into parts to make it more maintainable. For example with
> Grails' JSON views you may have several different templates that make up the
> entire JSON response.
> In order to support this we had to fork StreamingJsonBuilder and add the
> capability to pass a Writable as a value. The reason is, otherwise you have
> to buffer in memory an entire string for child template. For example now you
> would have to do something like this:
> {code}
> new StringWriter().with { w ->
> def builder = new StreamingJsonBuilder(w)
> def sw = new StringWriter()
>new StreamingJsonBuilder(sw).call {
> sectionId "world"
> }
> builder.response {
> status "ok"
> results sw.toString()
> }
> }
> {code}
> Which is inefficient and eliminates the memory benefits of streaming. Ideally
> you want to do this:
> {code}
> new StringWriter().with { w ->
> def builder = new StreamingJsonBuilder(w)
> def writable = new Writable() {
> @Override
> Writer writeTo(Writer writer) throws IOException {
> new StreamingJsonBuilder(writer).call {
> sectionId "world"
> }
> return writer
> }
> }
> builder.response {
> status "ok"
> results writable
> }
> }
> {code}
> Which allows you to continue streaming for child attributes of a JSON
> document.
> I have a pull request incoming for this improvement
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] groovy pull request #429: GROOVY-7946 - allow writable values for StreamingJ...
Github user asfgit closed the pull request at: https://github.com/apache/groovy/pull/429 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (GROOVY-7949) Disallow static inner classes within anonymous classes
[
https://issues.apache.org/jira/browse/GROOVY-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15527118#comment-15527118
]
Daniil Ovchinnikov commented on GROOVY-7949:
Java does not allow static members in inner classes
https://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-8.1.3
> Disallow static inner classes within anonymous classes
> --
>
> Key: GROOVY-7949
> URL: https://issues.apache.org/jira/browse/GROOVY-7949
> Project: Groovy
> Issue Type: Bug
>Reporter: Daniil Ovchinnikov
>
> This just does not make sense, but works:
> {code}
> def a = new Hello() {
> static class Hello {
> def foo() { "hello" }
> }
> }
> println a.foo()
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GROOVY-7949) Disallow static inner classes within anonymous classes
[
https://issues.apache.org/jira/browse/GROOVY-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15527101#comment-15527101
]
Jochen Theodorou commented on GROOVY-7949:
--
Does Java not allow this? I know it allows them in methods
> Disallow static inner classes within anonymous classes
> --
>
> Key: GROOVY-7949
> URL: https://issues.apache.org/jira/browse/GROOVY-7949
> Project: Groovy
> Issue Type: Bug
>Reporter: Daniil Ovchinnikov
>
> This just does not make sense, but works:
> {code}
> def a = new Hello() {
> static class Hello {
> def foo() { "hello" }
> }
> }
> println a.foo()
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (GROOVY-7949) Disallow static inner classes within anonymous classes
Daniil Ovchinnikov created GROOVY-7949:
--
Summary: Disallow static inner classes within anonymous classes
Key: GROOVY-7949
URL: https://issues.apache.org/jira/browse/GROOVY-7949
Project: Groovy
Issue Type: Bug
Reporter: Daniil Ovchinnikov
This just do not make sense, but works:
{code}
def a = new Hello() {
static class Hello {
def foo() { "hello" }
}
}
println a.foo()
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GROOVY-7949) Disallow static inner classes within anonymous classes
[
https://issues.apache.org/jira/browse/GROOVY-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniil Ovchinnikov updated GROOVY-7949:
---
Description:
This just does not make sense, but works:
{code}
def a = new Hello() {
static class Hello {
def foo() { "hello" }
}
}
println a.foo()
{code}
was:
This just do not make sense, but works:
{code}
def a = new Hello() {
static class Hello {
def foo() { "hello" }
}
}
println a.foo()
{code}
> Disallow static inner classes within anonymous classes
> --
>
> Key: GROOVY-7949
> URL: https://issues.apache.org/jira/browse/GROOVY-7949
> Project: Groovy
> Issue Type: Bug
>Reporter: Daniil Ovchinnikov
>
> This just does not make sense, but works:
> {code}
> def a = new Hello() {
> static class Hello {
> def foo() { "hello" }
> }
> }
> println a.foo()
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
