jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomek Rękawek (JIRA) <j...@apache.org>
Subject [jira] [Commented] (OAK-4882) Bottleneck in the asynchronous persistent cache
Date Tue, 25 Oct 2016 09:10:58 GMT

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

Tomek Rękawek commented on OAK-4882:
------------------------------------

I'm still working on reproducing the original issue in a controlled way.

In the meantime, I was thinking about the complexity of the asynchronous queue part of the
persistent cache (the {{org.apache.jackrabbit.oak.plugins.document.persistentCache.async}}
package). Most of it is caused by the fact, that the queue guarantees that each {{put()}}
operation will be either (1) executed or (2) replaced with {{invalidate()}} if the queue becomes
full.

The requirement (2) was introduced to avoid stale cache entries. However, right now the cache
values are immutable anyway (as their key is path+revision). I think we should use this property
to simplify the asynchronous queue (and therefore improve the performance).

In the OAK-2761 Marcel [mentioned|https://issues.apache.org/jira/browse/OAK-2761?focusedCommentId=15130422&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15130422]
that the PersistenceCache is a general mechanism and that the immutability property may not
be hold for the future uses. However, I think we should first improve the existing implementation
(especially that we already know about a few Oak customers dealing with the described bottleneck)
and worry about the mutable cases if/when they appear. It seems that the current solution
won't work for these cases anyway.

I'll try to make it clear in the code that the asynchronous queue only works for PersistentCache
cases storing immutable values, so it won't hit us in the future.

WDYT?

//cc: [~tmueller], [~chetanm], [~mreutegg]

> 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
>
>
> 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)

Mime
View raw message