Description
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-10506and 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.