[jira] [Commented] (OAK-9678) CacheLIRS should not use synchronized

["Thomas Mueller (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-9678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17483747#comment-17483747 ] 

Thomas Mueller commented on OAK-9678:
-------------------------------------

According to my experience, with 99.9% probability the problem has nothing to do with using "synchronized" over "ReentrantReadWriteLock".

> CacheLIRS should not use synchronized
> -------------------------------------
>
>                 Key: OAK-9678
>                 URL: https://issues.apache.org/jira/browse/OAK-9678
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 1.40.0
>            Reporter: Joerg Hoh
>            Priority: Major
>
> I am analyzing a situation, where I get actually hundreds of threads having a stacktrace like this:
> {noformat}
> 74.118.98.131 [1643218398059] GET /mnt/overlay/granite/ui/content/shell/header/actions/pulse.data.json HTTP/1.1" #58 prio=5 os_prio=0 cpu=26006.94ms elapsed=1206.98s tid=0x0000560a69765000 nid=0x138d waiting for monitor entry  [0x00007f8f1b15b000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
>         at org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.access(CacheLIRS.java:910)
>         - waiting to lock <0x00000006a1c5c1a0> (a org.apache.jackrabbit.oak.cache.CacheLIRS$Segment)
>         at org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.get(CacheLIRS.java:893)
>         at org.apache.jackrabbit.oak.cache.CacheLIRS$Segment.get(CacheLIRS.java:958)
>         at org.apache.jackrabbit.oak.cache.CacheLIRS.get(CacheLIRS.java:299)
>         at org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.getNode(DocumentNodeStore.java:1271)
>         at org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore$8.apply(DocumentNodeStore.java:1449)
>         at org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore$8.apply(DocumentNodeStore.java:1445)
> {noformat}
> Checking the code at [1] the most basic Java synchronization mechanism (the {{synchronized}} keyword) is used. According to this DZone article [2] this can be problematic, as with every thread leaving such a synchronized block all threads waiting for this lock ware woken up but only 1 thread might enter this section; the others are sent back to sleep. It recommends to use a ReentrantReadWriteLock instead, which is much smarter and just wakes up 1 thread.
> In my situation I had a huge CPU usage during that situation, which I am not able to explain because the threaddumps did show that there was hardly any other thread working there, but the vast majority were blocked like above.
> While I think, that such an improvement might now have fully avoided the problem I face I think that such an optimization is still useful. This is a heavily used code-path and if there's a way to reduce the overhead of locking itself it would highly useful.
> [1] https://github.com/apache/jackrabbit-oak/blob/08eab301c869c227d8721da0e9b9bd3d2029d458/oak-core-spi/src/main/java/org/apache/jackrabbit/oak/cache/CacheLIRS.java#L909
> [2] https://dzone.com/articles/synchronized-considered



--
This message was sent by Atlassian Jira
(v8.20.1#820001)