Joerg Hoh created SLING-12344:
---------------------------------
Summary: Lock contention in ScriptDependencyResolver
Key: SLING-12344
URL: https://issues.apache.org/jira/browse/SLING-12344
Project: Sling
Issue Type: Task
Components: HTL
Affects Versions: Scripting HTL Engine 1.4.22-1.4.0
Reporter: Joerg Hoh
I see threaddumps which show lock contention in the ScriptDependencyResolver
like this:
{noformat}
at jdk.internal.misc.Unsafe.park([email protected]/Native Method)
- parking to wait for <0x0000000496e16af0> (a
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
at
java.util.concurrent.locks.LockSupport.park([email protected]/LockSupport.java:194)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt([email protected]/AbstractQueuedSynchronizer.java:885)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued([email protected]/AbstractQueuedSynchronizer.java:917)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire([email protected]/AbstractQueuedSynchronizer.java:1240)
at
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock([email protected]/ReentrantReadWriteLock.java:959)
at
org.apache.sling.scripting.sightly.impl.utils.ScriptDependencyResolver.resolveScript(ScriptDependencyResolver.java:100)
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)
at apps.components.x.y.y__002e__html.render(y__002e__html.java:39)
{noformat}
but also:
{noformat}
at jdk.internal.misc.Unsafe.park([email protected]/Native Method)
- parking to wait for <0x0000000496e16af0> (a
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
at
java.util.concurrent.locks.LockSupport.park([email protected]/LockSupport.java:194)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt([email protected]/AbstractQueuedSynchronizer.java:885)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared([email protected]/AbstractQueuedSynchronizer.java:1009)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared([email protected]/AbstractQueuedSynchronizer.java:1324)
at
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock([email protected]/ReentrantReadWriteLock.java:738)
at
org.apache.sling.scripting.sightly.impl.utils.ScriptDependencyResolver.resolveScript(ScriptDependencyResolver.java:93)
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)
at apps.components.a.b.b__002e__html$3.render(b__002e__html.java:218)
{noformat}
I see that the ScriptDependencyResolver holds cache, which just saves positive
results where the result has been found; if the result is null, it's not
cached, and it will be attempted over and over again.
Of course this situation mostly happens if a lot of these requests with invalid
scriptIdentifiers are done, which points to problems in the content. But it
would be great if the code behaves a bit better here, because I have a
situation here where requests holding the write lock block all other requests
which would have a cache hit.
(Thinking further, I don't really understand why a ReadWrite lock is used here
at all. As far as I can see a ConcurrentHashMap as a cache should be
sufficient.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
