[jira] [Comment Edited] (OAK-4882) Bottleneck in the asynchronous persistent cache
[ https://issues.apache.org/jira/browse/OAK-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15614762#comment-15614762 ] Tomek Rękawek edited comment on OAK-4882 at 11/4/16 7:48 PM: - I committed the async queue simplified as in the discussion above. The commit also includes heuristics suggest by Chetan. Trunk: [r1766966|https://svn.apache.org/r1766966], [r1766992|https://svn.apache.org/r1766992], [r1767661|https://svn.apache.org/r1767661], [r1767991|https://svn.apache.org/r1767991], [r1768084|https://svn.apache.org/r1768084]. 1.4: [r1766970|https://svn.apche.org/r1766970], [r1766993|https://svn.apache.org/r1766993], [r1767662|https://svn.apache.org/r1767662], [r1767992|https://svn.apache.org/r1767992]. was (Author: tomek.rekawek): I committed the async queue simplified as in the discussion above. The commit also includes heuristics suggest by Chetan. Trunk: [r1766966|https://svn.apache.org/r1766966], [r1766992|https://svn.apache.org/r1766992], [r1767661|https://svn.apache.org/r1767661], [r1767991|https://svn.apache.org/r1767991]. 1.4: [r1766970|https://svn.apche.org/r1766970], [r1766993|https://svn.apache.org/r1766993], [r1767662|https://svn.apache.org/r1767662], [r1767992|https://svn.apache.org/r1767992]. > Bottleneck in the asynchronous persistent cache > --- > > Key: OAK-4882 > URL: https://issues.apache.org/jira/browse/OAK-4882 > Project: Jackrabbit Oak > Issue Type: Bug > Components: cache, documentmk >Affects Versions: 1.5.10, 1.4.8 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek > Fix For: 1.6, 1.5.13, 1.4.10 > > Attachments: OAK-4882.patch > > > The class responsible for accepting new cache operations which will be > handled asynchronously is > [CacheActionDispatcher|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java]. > In case of a high load, when the queue is full (=1024 entries), the > [add()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L86] > method removes the oldest 256 entries. However, we can't afford losing the > updates (as it may result in having stale entries in the cache), so all the > removed entries are compacted into one big invalidate action. > The compaction action > ([CacheActionDispatcher#cleanTheQueue|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L97]) > still holds the lock taken in add() method, so threads which tries to add > something to the queue have to wait until cleanTheQueue() ends. > Maybe we can optimise the CacheActionDispatcher#add->cleanTheQueue part, so > it won't hold the lock for the whole time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4882) Bottleneck in the asynchronous persistent cache
[ https://issues.apache.org/jira/browse/OAK-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15614762#comment-15614762 ] Tomek Rękawek edited comment on OAK-4882 at 11/4/16 8:25 AM: - I committed the async queue simplified as in the discussion above. The commit also includes heuristics suggest by Chetan. Trunk: [r1766966|https://svn.apache.org/r1766966], [r1766992|https://svn.apache.org/r1766992], [r1767661|https://svn.apache.org/r1767661], [r1767991|https://svn.apache.org/r1767991]. 1.4: [r1766970|https://svn.apche.org/r1766970], [r1766993|https://svn.apache.org/r1766993], [r1767662|https://svn.apache.org/r1767662], [r1767992|https://svn.apache.org/r1767992]. was (Author: tomek.rekawek): I committed the async queue simplified as in the discussion above. The commit also includes heuristics suggest by Chetan. Trunk: [r1766966|https://svn.apache.org/r1766966], [r1766992|https://svn.apache.org/r1766992], [r1767661|https://svn.apache.org/r1767661], [r1767991|https://svn.apache.org/r1767991]. 1.4: [r1766970|https://svn.apche.org/r1766970], [r1766993|https://svn.apache.org/r1766993], [r1767662|https://svn.apache.org/r1767662]. > Bottleneck in the asynchronous persistent cache > --- > > Key: OAK-4882 > URL: https://issues.apache.org/jira/browse/OAK-4882 > Project: Jackrabbit Oak > Issue Type: Bug > Components: cache, documentmk >Affects Versions: 1.5.10, 1.4.8 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek > Fix For: 1.6, 1.5.13, 1.4.10 > > Attachments: OAK-4882.patch > > > The class responsible for accepting new cache operations which will be > handled asynchronously is > [CacheActionDispatcher|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java]. > In case of a high load, when the queue is full (=1024 entries), the > [add()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L86] > method removes the oldest 256 entries. However, we can't afford losing the > updates (as it may result in having stale entries in the cache), so all the > removed entries are compacted into one big invalidate action. > The compaction action > ([CacheActionDispatcher#cleanTheQueue|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L97]) > still holds the lock taken in add() method, so threads which tries to add > something to the queue have to wait until cleanTheQueue() ends. > Maybe we can optimise the CacheActionDispatcher#add->cleanTheQueue part, so > it won't hold the lock for the whole time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4882) Bottleneck in the asynchronous persistent cache
[ https://issues.apache.org/jira/browse/OAK-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15614762#comment-15614762 ] Tomek Rękawek edited comment on OAK-4882 at 11/4/16 8:23 AM: - I committed the async queue simplified as in the discussion above. The commit also includes heuristics suggest by Chetan. Trunk: [r1766966|https://svn.apache.org/r1766966], [r1766992|https://svn.apache.org/r1766992], [r1767661|https://svn.apache.org/r1767661], [r1767991|https://svn.apache.org/r1767991]. 1.4: [r1766970|https://svn.apche.org/r1766970], [r1766993|https://svn.apache.org/r1766993], [r1767662|https://svn.apache.org/r1767662]. was (Author: tomek.rekawek): I committed the async queue simplified as in the discussion above. The commit also includes heuristics suggest by Chetan. Trunk: [r1766966|https://svn.apache.org/r1766966], [r1766992|https://svn.apache.org/r1766992], [r1767661|https://svn.apache.org/r1767661]. 1.4: [r1766970|https://svn.apche.org/r1766970], [r1766993|https://svn.apache.org/r1766993], [r1767662|https://svn.apache.org/r1767662]. > Bottleneck in the asynchronous persistent cache > --- > > Key: OAK-4882 > URL: https://issues.apache.org/jira/browse/OAK-4882 > Project: Jackrabbit Oak > Issue Type: Bug > Components: cache, documentmk >Affects Versions: 1.5.10, 1.4.8 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek > Fix For: 1.6, 1.5.13, 1.4.10 > > Attachments: OAK-4882.patch > > > The class responsible for accepting new cache operations which will be > handled asynchronously is > [CacheActionDispatcher|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java]. > In case of a high load, when the queue is full (=1024 entries), the > [add()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L86] > method removes the oldest 256 entries. However, we can't afford losing the > updates (as it may result in having stale entries in the cache), so all the > removed entries are compacted into one big invalidate action. > The compaction action > ([CacheActionDispatcher#cleanTheQueue|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L97]) > still holds the lock taken in add() method, so threads which tries to add > something to the queue have to wait until cleanTheQueue() ends. > Maybe we can optimise the CacheActionDispatcher#add->cleanTheQueue part, so > it won't hold the lock for the whole time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4882) Bottleneck in the asynchronous persistent cache
[ https://issues.apache.org/jira/browse/OAK-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15629029#comment-15629029 ] Tomek Rękawek edited comment on OAK-4882 at 11/2/16 1:51 PM: - Using stats from OAK-5038 it is possible to measure how many entries are rejected because of the full queue. It seems that the don't-write-persisted-entries-again condition helps a great deal here. After enabling it, the queue performance is enough to process all the entries (nothing is rejected at all). As a test I started Sling-based CMS on Mongo - it creates a lot of content during its initialisation. was (Author: tomek.rekawek): Using stats from OAK-5038 it is possible to measure how many entries are rejected because of the full queue. It seems that the don't-write-persisted-entries-again condition helps a great deal here. After enabling it, the queue performance is enough to process all the entries (nothing is rejected at all). As a test I started Sling-based CMS on Mongo - it creates a lot of content during its initialisation. I think we should use the same heuristics for the default, synchronous case. > Bottleneck in the asynchronous persistent cache > --- > > Key: OAK-4882 > URL: https://issues.apache.org/jira/browse/OAK-4882 > Project: Jackrabbit Oak > Issue Type: Bug > Components: cache, documentmk >Affects Versions: 1.5.10, 1.4.8 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek > Fix For: 1.6, 1.5.13, 1.4.10 > > Attachments: OAK-4882.patch > > > The class responsible for accepting new cache operations which will be > handled asynchronously is > [CacheActionDispatcher|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java]. > In case of a high load, when the queue is full (=1024 entries), the > [add()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L86] > method removes the oldest 256 entries. However, we can't afford losing the > updates (as it may result in having stale entries in the cache), so all the > removed entries are compacted into one big invalidate action. > The compaction action > ([CacheActionDispatcher#cleanTheQueue|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L97]) > still holds the lock taken in add() method, so threads which tries to add > something to the queue have to wait until cleanTheQueue() ends. > Maybe we can optimise the CacheActionDispatcher#add->cleanTheQueue part, so > it won't hold the lock for the whole time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4882) Bottleneck in the asynchronous persistent cache
[ https://issues.apache.org/jira/browse/OAK-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15614762#comment-15614762 ] Tomek Rękawek edited comment on OAK-4882 at 11/2/16 12:43 PM: -- I committed the async queue simplified as in the discussion above. The commit also includes heuristics suggest by Chetan. Trunk: [r1766966|https://svn.apache.org/r1766966], [r1766992|https://svn.apache.org/r1766992], [r1767661|https://svn.apache.org/r1767661]. 1.4: [r1766970|https://svn.apche.org/r1766970], [r1766993|https://svn.apache.org/r1766993], [r1767662|https://svn.apache.org/r1767662]. was (Author: tomek.rekawek): I committed the async queue simplified as in the discussion above. The commit also includes heuristics suggest by Chetan. Trunk: [r1766966|https://svn.apache.org/r1766966], [r1766992|https://svn.apache.org/r1766992]. 1.4: [r1766970|https://svna.apche.org/r1766970], [r1766993|https://svn.apache.org/r1766993]. > Bottleneck in the asynchronous persistent cache > --- > > Key: OAK-4882 > URL: https://issues.apache.org/jira/browse/OAK-4882 > Project: Jackrabbit Oak > Issue Type: Bug > Components: cache, documentmk >Affects Versions: 1.5.10, 1.4.8 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek > Fix For: 1.6, 1.5.13 > > Attachments: OAK-4882.patch > > > The class responsible for accepting new cache operations which will be > handled asynchronously is > [CacheActionDispatcher|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java]. > In case of a high load, when the queue is full (=1024 entries), the > [add()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L86] > method removes the oldest 256 entries. However, we can't afford losing the > updates (as it may result in having stale entries in the cache), so all the > removed entries are compacted into one big invalidate action. > The compaction action > ([CacheActionDispatcher#cleanTheQueue|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L97]) > still holds the lock taken in add() method, so threads which tries to add > something to the queue have to wait until cleanTheQueue() ends. > Maybe we can optimise the CacheActionDispatcher#add->cleanTheQueue part, so > it won't hold the lock for the whole time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4882) Bottleneck in the asynchronous persistent cache
[ https://issues.apache.org/jira/browse/OAK-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15614762#comment-15614762 ] Tomek Rękawek edited comment on OAK-4882 at 10/28/16 9:45 AM: -- I committed the async queue simplified as in the discussion above. The commit also includes heuristics suggest by Chetan. Trunk: [r1766966|https://svn.apache.org/r1766966], [r1766992|https://svn.apache.org/r1766992]. 1.4: [r1766970|https://svna.apche.org/r1766970], [r1766993|https://svn.apache.org/r1766993]. was (Author: tomek.rekawek): I committed the async queue simplified as in the discussion above. The commit also includes heuristics suggest by Chetan. Trunk: [r1766966|https://svn.apache.org/r1766966], [r1766992|https://svn.apache.org/r1766992]. 1.4: [r1766970|https://svna.apche.org/r1766970]. > Bottleneck in the asynchronous persistent cache > --- > > Key: OAK-4882 > URL: https://issues.apache.org/jira/browse/OAK-4882 > Project: Jackrabbit Oak > Issue Type: Bug > Components: cache, documentmk >Affects Versions: 1.5.10, 1.4.8 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek > Fix For: 1.6, 1.5.13 > > Attachments: OAK-4882.patch > > > The class responsible for accepting new cache operations which will be > handled asynchronously is > [CacheActionDispatcher|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java]. > In case of a high load, when the queue is full (=1024 entries), the > [add()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L86] > method removes the oldest 256 entries. However, we can't afford losing the > updates (as it may result in having stale entries in the cache), so all the > removed entries are compacted into one big invalidate action. > The compaction action > ([CacheActionDispatcher#cleanTheQueue|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L97]) > still holds the lock taken in add() method, so threads which tries to add > something to the queue have to wait until cleanTheQueue() ends. > Maybe we can optimise the CacheActionDispatcher#add->cleanTheQueue part, so > it won't hold the lock for the whole time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4882) Bottleneck in the asynchronous persistent cache
[ https://issues.apache.org/jira/browse/OAK-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15614762#comment-15614762 ] Tomek Rękawek edited comment on OAK-4882 at 10/28/16 9:44 AM: -- I committed the async queue simplified as in the discussion above. The commit also includes heuristics suggest by Chetan. Trunk: [r1766966|https://svn.apache.org/r1766966], [r1766992|https://svn.apache.org/r1766992]. 1.4: [r1766970|https://svna.apche.org/r1766970]. was (Author: tomek.rekawek): I committed the async queue simplified as in the discussion above. The commit also includes heuristics suggest by Chetan. Trunk: [r1766966|https://svn.apache.org/r1766966] 1.4: [r1766970|https://svna.apche.org/r1766970]. > Bottleneck in the asynchronous persistent cache > --- > > Key: OAK-4882 > URL: https://issues.apache.org/jira/browse/OAK-4882 > Project: Jackrabbit Oak > Issue Type: Bug > Components: cache, documentmk >Affects Versions: 1.5.10, 1.4.8 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek > Fix For: 1.6, 1.5.13 > > Attachments: OAK-4882.patch > > > The class responsible for accepting new cache operations which will be > handled asynchronously is > [CacheActionDispatcher|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java]. > In case of a high load, when the queue is full (=1024 entries), the > [add()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L86] > method removes the oldest 256 entries. However, we can't afford losing the > updates (as it may result in having stale entries in the cache), so all the > removed entries are compacted into one big invalidate action. > The compaction action > ([CacheActionDispatcher#cleanTheQueue|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L97]) > still holds the lock taken in add() method, so threads which tries to add > something to the queue have to wait until cleanTheQueue() ends. > Maybe we can optimise the CacheActionDispatcher#add->cleanTheQueue part, so > it won't hold the lock for the whole time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4882) Bottleneck in the asynchronous persistent cache
[ https://issues.apache.org/jira/browse/OAK-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15614788#comment-15614788 ] Chetan Mehrotra edited comment on OAK-4882 at 10/28/16 8:50 AM: [~tomek.rekawek] It would be helpful to invest in some benchmark which can reproduce the issue and validate any approach against that. Otherwise we may hit issue somewhere else. Also I would feel more comfortable if this change gets some more test runs before we merge it to branch. was (Author: chetanm): [~tomek.rekawek] It would be helpful to invest in some benchmark which can reproduce the issue and validate any approach against that. Otherwise we may hit issue somewhere else. > Bottleneck in the asynchronous persistent cache > --- > > Key: OAK-4882 > URL: https://issues.apache.org/jira/browse/OAK-4882 > Project: Jackrabbit Oak > Issue Type: Bug > Components: cache, documentmk >Affects Versions: 1.5.10, 1.4.8 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek > Fix For: 1.6, 1.5.13 > > Attachments: OAK-4882.patch > > > The class responsible for accepting new cache operations which will be > handled asynchronously is > [CacheActionDispatcher|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java]. > In case of a high load, when the queue is full (=1024 entries), the > [add()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L86] > method removes the oldest 256 entries. However, we can't afford losing the > updates (as it may result in having stale entries in the cache), so all the > removed entries are compacted into one big invalidate action. > The compaction action > ([CacheActionDispatcher#cleanTheQueue|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L97]) > still holds the lock taken in add() method, so threads which tries to add > something to the queue have to wait until cleanTheQueue() ends. > Maybe we can optimise the CacheActionDispatcher#add->cleanTheQueue part, so > it won't hold the lock for the whole time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-4882) Bottleneck in the asynchronous persistent cache
[ https://issues.apache.org/jira/browse/OAK-4882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15614762#comment-15614762 ] Tomek Rękawek edited comment on OAK-4882 at 10/28/16 8:43 AM: -- I committed the async queue simplified as in the discussion above. The commit also includes heuristics suggest by Chetan. Trunk: [r1766966|https://svn.apache.org/r1766966] 1.4: [r1766970|https://svna.apche.org/r1766970]. was (Author: tomek.rekawek): I committed the async queue simplified as in the discussion above. The commit also includes heuristics suggest by Chetan. Trunk: [r1766966|https://svn.apache.org/r1766966] > Bottleneck in the asynchronous persistent cache > --- > > Key: OAK-4882 > URL: https://issues.apache.org/jira/browse/OAK-4882 > Project: Jackrabbit Oak > Issue Type: Bug > Components: cache, documentmk >Affects Versions: 1.5.10, 1.4.8 >Reporter: Tomek Rękawek >Assignee: Tomek Rękawek > Fix For: 1.6, 1.5.13 > > Attachments: OAK-4882.patch > > > The class responsible for accepting new cache operations which will be > handled asynchronously is > [CacheActionDispatcher|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java]. > In case of a high load, when the queue is full (=1024 entries), the > [add()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L86] > method removes the oldest 256 entries. However, we can't afford losing the > updates (as it may result in having stale entries in the cache), so all the > removed entries are compacted into one big invalidate action. > The compaction action > ([CacheActionDispatcher#cleanTheQueue|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.java#L97]) > still holds the lock taken in add() method, so threads which tries to add > something to the queue have to wait until cleanTheQueue() ends. > Maybe we can optimise the CacheActionDispatcher#add->cleanTheQueue part, so > it won't hold the lock for the whole time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
