Keeping ScriptEngine per Thread?

[Frantzius, Jörg]

Hi Sundar,

thanks for your answer. So that seems to mean that ScriptEngine per se is thread-safe, and we can isolate threads by providing separate ScriptContexts. It’s good to know we can use a singleton ScriptEngine in case memory footprint turns out to be too big.

Thx + regards,
Jörg

---

Dipl. Inf. Jörg von Frantzius, Technical Director

E-Mail joerg.frantzius at aperto.com

Phone +49 30 283921-0
Fax +49 30 283921-29

Aperto AG - In der Pianofabrik
Chausseestraße 5, D-10115 Berlin
http://www.aperto.com<http://www.aperto.de/>
http://www.facebook.com/aperto
https://www.xing.com/companies/apertoag

HRB 77049 B, AG Berlin Charlottenburg
Vorstand: Dirk Buddensiek (Vorsitzender), Kai Großmann, Stephan Haagen, Daniel Simon
Aufsichtsrat: Bernd Hardes (Vorsitzender)

Am 09.12.2015 um 10:55 schrieb Sundararajan Athijegannathan <sundararajan.athijegannathan at oracle.com<mailto:sundararajan.athijegannathan at oracle.com>>:

One engine per worker thread would definitely work - this is maximum isolation. This mode even avoids sharing script classers / loaders.

If that is not workable in your use-case, you can use a separate ENGINE_SCOPE bindings (or separate ScriptContext) per thread. This will separate ECMAScript globals to be thread specific. This mode allows for script Class (compiled/loaded script Class objects) to be shared -- but global state is not. This is partial sharing - but safe.

If you do share the default ScriptContext of the script engine across threads, then it is up to you to take care of MT access/modification of globals -- you could still carefully structure code to run script functions in a such a way to avoid concurrent global modifications - but it'd be practically difficult.

Hope this helps,
-Sundar

On 12/9/2015 2:58 PM, Frantzius, Jörg wrote:
Hi,

we’re using Oracle JDK’s Nashorn in a web application, where it is used to render HTML markup in HTTP worker threads.

I remember having read somewhere that the creation of a ScriptEngine (i.e. invocation of ScriptEngineFactory.getScriptEngine()) may have considerable performance overhead, so probably it should be avoided to do this with every incoming HTTP request. This is why we’ll go for keeping a ScriptEngine per thread in a ThreadLocal.

On the other hand this may result in a large memory footprint, as there can be 200 HTTP worker threads, but we don’t have any experience with it yet.

The ScriptEngineFactory.getParameter() Javadocs<http://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/NashornScriptEngineFactory.html#getParameter-java.lang.String-> does list some interesting parameters for the key „THREADING“, that seem to make it possible to have a singleton ScriptEngine instead, which could be used concurrently from multiple threads. However, I have no clue whether this is either supported by Nashorn, nor how to set this parameter on engine creation.

Is there per chance some recommended usage pattern for ScriptEngine in a web server?

Thanks for any insights,
Jörg


---

Dipl. Inf. Jörg von Frantzius, Technical Director

E-Mail joerg.frantzius at aperto.com<mailto:joerg.frantzius at aperto.com>

Phone +49 30 283921-0
Fax +49 30 283921-29

Aperto AG - In der Pianofabrik
Chausseestraße 5, D-10115 Berlin
http://www.aperto.com<http://www.aperto.de/>
http://www.facebook.com/aperto
https://www.xing.com/companies/apertoag

HRB 77049 B, AG Berlin Charlottenburg
Vorstand: Dirk Buddensiek (Vorsitzender), Kai Großmann, Stephan Haagen, Daniel Simon
Aufsichtsrat: Bernd Hardes (Vorsitzender)