[SLING-12473] Lock contention in ScriptDependencyResolver (2)

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: Scripting HTL Engine 1.4.24-1.4.0
• Fix Version/s: Scripting HTL Engine 1.4.26-1.4.0
• Component/s: HTL
• Assignee: Joerg Hoh
• Reporter: Joerg Hoh
• Created: 06/Nov/24 17:24
• Updated: Yesterday 18:20
• Resolved: 20/Nov/24 13:44

Description

This is a follow-up of SLING-12344.

Even with the improvements added by SLING-12344 I see these stacktraces, especially when an instance is just starting up.

 at jdk.internal.misc.Unsafe.park(java.base@11.0.23/Native Method)
        - parking to wait for  <0x0000000469fbac10> (a java.util.concurrent.locks.ReentrantReadWriteLock$FairSync)
        at java.util.concurrent.locks.LockSupport.park(java.base@11.0.23/LockSupport.java:194)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.23/AbstractQueuedSynchronizer.java:885)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(java.base@11.0.23/AbstractQueuedSynchronizer.java:1009)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(java.base@11.0.23/AbstractQueuedSynchronizer.java:1324)
        at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(java.base@11.0.23/ReentrantReadWriteLock.java:738)
        at org.apache.sling.scripting.sightly.impl.utils.ScriptDependencyResolver.resolveScript(ScriptDependencyResolver.java:127)
        at org.apache.sling.scripting.sightly.impl.engine.extension.use.RenderUnitProvider.provide(RenderUnitProvider.java:95)
        at org.apache.sling.scripting.sightly.impl.engine.extension.use.UseRuntimeExtension.call(UseRuntimeExtension.java:71)
        at org.apache.sling.scripting.sightly.impl.engine.runtime.RenderContextImpl.call(RenderContextImpl.java:72)

It seems to me that the current code always acquires a read lock when entering the method. And that whenever one thread holds the write lock tp update the cache, all threads invoking the resolveScript method get blocked until the write lock is released. And this happens even for requests which would get a cache hit.
For that reason as long as entries are added to this cache at a high frequency, threads invoking ScriptDependencyResolver.resolveScript() have a high chance of being blocked by this.

Possible mitigations:

• Disable the caching by setting the ScriptResolutionCacheSize in the HTL Engine to a value less than 1024; this can be used as workaround.
• refactor the code, so that cache hits can be served without acquiring the read lock.
• refactor the code to use a ConcurrentHashMap, as cziegeler already suggested in the context SLING-12344 (Link). This would allow to grow the map without limits, but I don't consider this a major problem, as the number of keys (resourcetype + scriptIdentifier) is limited by the application itself, and the values are just strings, so it's unlikely to cause a memory problem.

Note: SLING-12471 is unrelated to this specific problem!

Issue Links

• links to: GitHub Pull Request #29