Following same analysis of Bug 57114 and as per understanding of this: - https://stackoverflow.com/questions/48644849/is-groovy-scriptingengine-thread-safe Groovy ScriptEngine "THREADING" is equal to MULTITHREADED: - https://docs.oracle.com/javase/8/docs/api/javax/script/ScriptEngineFactory.html#getParameter-java.lang.String- It seems we could avoid the synchronized block. Thoughts ? Thanks
It does look like the synchronization there is not needed.
(In reply to Vladimir Sitnikov from comment #1) > It does look like the synchronization there is not needed. Hi Vladimir, Would you say that this answer is correct : - https://stackoverflow.com/q/48648931/460802 IMO, it is. If we remove the synchronization, my understanding is that: - there is a risk if Groovy script uses global variables, there is no reason to do that - I am not sure about the risk on GroovyClassLoader. I don't think there is as per what is described here: http://docs.groovy-lang.org/latest/html/documentation/guide-integrating.html#groovyclassloader Is my understanding correct ? Thanks
>- https://stackoverflow.com/q/48648931/460802 The link seems to not related to Groovy. >- there is a risk if Groovy script uses global variables, there is no reason to do that I agree, there's a little reason to do that. We might want to document how to avoid global variables. >- I am not sure about the risk on GroovyClassLoader. I don't think there is as per what is described here: As far as I can understand, it means "use of Apache JMeter string interpolation inside Groovy scripts would result in OutOfMemoryError". In other words, the best practice is to keep script string constant and pass all the params via parameters and/or Apache JMeter variables.
The correct link is: https://stackoverflow.com/questions/48644849/is-groovy-scriptingengine-thread-safe
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/4687