https://bz.apache.org/bugzilla/show_bug.cgi?id=59946

            Bug ID: 59946
           Summary: Memory leak at JSR223 components with Groovy script
           Product: JMeter
           Version: 3.0
          Hardware: PC
                OS: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: Main
          Assignee: [email protected]
          Reporter: [email protected]

Created attachment 34103
  --> https://bz.apache.org/bugzilla/attachment.cgi?id=34103&action=edit
Sample test file to show memory leak

I noticed that there is major increase at memory usage when JSR223 components
are used without caching the compiled script. The attached test script contains
only JSR223 sampler with script "def x = 1 + 1" which should not leak memory.
But if you execute it, you quickly notice that it increases the memory usage.

This does not affect to JMeter if the compiled script is cached. So I recommend
it, but still this can be an issue.

The dump shows that the leaked elements are
org.codehaus.groovy.reflection.ClassInfo. I've attached Eclipse MAT rerpot as
ZIP package. 

I've experimented and investiaged multiple solutions. I've attached an example
solution for JSR223Sampler.java, but I'm not sure if this solution is
acceptable. Basically the problem is, that when we create new script engine
ScriptEngineManager.getEngineByName(lang), the Groovy engine loses its cache
reference, but still adds the information about the script to cache. For that
reason it creates new script to cache each time when the script is executed.
This at the end fills the memory with the Groovy's ClassInfo. 

Based to the answer abotu thread safety of Groovy
(http://stackoverflow.com/questions/30140103/should-i-use-a-separate-scriptengine-and-compiledscript-instances-per-each-threa),
only single ScriptEngine could be created for all threads. But does that cause
problems with other script engines? 

This same issue is with pre- and post-processor, and I suppose it is with all
other JSR223 elements also.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to