Concurrency defect in ScriptingEngines

org.flowable.common.engine.impl.scripting.ScriptingEngines is using a regular HashMap<> for its cachedEngines cache.

In a concurrent context I am seeing the same Flowable engine creating one Groovy engine per thread as a result (and luckily the Map didn’t get corrupted).

I’d recommend a ConcurrentHashMap, and a synchronized block to check & create missing entries.

BTW a related defect in Groovy this time, org.codehaus.groovy.jsr223.GroovyScriptEngineImpl#getScriptClass uses a ManagedConcurrentValueMap custom Map that is supposed to be thread safe, however I am seeing 0 cache hits and loader.parseClass being called once per process instance in a concurrent setting.

A concurrent hashmaps alone should not be relied on for caches: they won’t crash or corrupt the data structure sure, but w/o a synchronized block they cannot ensure cache hits.

See java - Cache using ConcurrentHashMap - Stack Overflow for example