Scenario:

• I deploy a process with two Javascript script tasks and run the process. Both tasks use the S function from Spin.

Current behavior:

• First task succeeds
• Second fails, because it cannot find S

Expected behavior:

• Both tasks are successful

Root cause:

• Script compilation is currently enabled by default (see CAM-10506)
• A compiled Nashorn script references its script engine; A variable defined by such a script can only be referenced by another script that was compiled with the same script engine
• We do not cache Nashorn script engines
• The first script succeeds, because both the environment script defining S, as well as the actual script are compiled with the same scripting engine
• The second script fails, because the actual script is compiled with a different engine than the (previously compiled) environment script

Solution approaches:

• Short-term: Revert changes of CAM-10506 and have a test for this case
• Long term ideas: Evaluate if script engine caching for Nashorn is possible (not clear, we check this via scriptEngine.getFactory().getParameter("THREADING");, see org.camunda.bpm.engine.impl.scripting.engine.ScriptEngineResolver.isCachable(ScriptEngine). Nashorn returns null indicating a scripting engine is not thread-safe). Even if we cache the scripting engine, we must still be aware that we cache scripting engines at different levels (engine-global and process-application-local), so that may require that we keep up to one compiled script per source script on each of these levels. Before we go in this direction, we must have a very good understanding how script compilation and evaluation in Nashorn works (e.g. where the S function ends up when its environment script is evaluated)

We will go with the short-term solution to avoid regressions.