[
https://issues.apache.org/jira/browse/OAK-2761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-2761:
----------------------------------
Attachment: AsyncCacheTest.patch
Thanks Tomek for looking into this improvement.
The tricky part is indeed how to correctly implement operation that affect
items currently in the queue. I think there are potentially many more
operations that can be affected by items in the queue. The example you provide
is just one of those cases. The attached test shows another problem when
invalidate() is called for an item currently in the queue. The item eventually
reappears. I'm also wondering what happens when multiple put operations happen
for the same key. If the first put makes it into the persisted map, but the
second one is evicted from the queue because it became full, the NodeCache may
at some point return the value of the first put operation.
In practice this is most likely not an issue at the moment because we only have
one or two usages of invalidate(). I still think we must ensure the
implementation behaves according to the contract, otherwise we run into
surprises later.
> Persistent cache: add data in a different thread
> ------------------------------------------------
>
> Key: OAK-2761
> URL: https://issues.apache.org/jira/browse/OAK-2761
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: cache, core, mongomk
> Reporter: Thomas Mueller
> Assignee: Thomas Mueller
> Labels: resilience
> Fix For: 1.4
>
> Attachments: AsyncCacheTest.patch, OAK-2761-1.2.patch,
> OAK-2761-trunk.patch
>
>
> The persistent cache usually stores data in a background thread, but
> sometimes (if a lot of data is added quickly) the foreground thread is
> blocked.
> Even worse, switching the cache file can happen in a foreground thread, with
> the following stack trace.
> {noformat}
> "127.0.0.1 [1428931262206] POST /bin/replicate.json HTTP/1.1" prio=5
> tid=0x00007fe5df819800 nid=0x9907 runnable [0x0000000113fc4000]
> java.lang.Thread.State: RUNNABLE
> ...
> at org.h2.mvstore.MVStoreTool.compact(MVStoreTool.java:404)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1.closeStore(PersistentCache.java:213)
> - locked <0x0000000782483050> (a
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache$1)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.switchGenerationIfNeeded(PersistentCache.java:350)
> - locked <0x0000000782455710> (a
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.NodeCache.write(NodeCache.java:85)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.NodeCache.put(NodeCache.java:130)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.applyChanges(DocumentNodeStore.java:1060)
> at
> org.apache.jackrabbit.oak.plugins.document.Commit.applyToCache(Commit.java:599)
> at
> org.apache.jackrabbit.oak.plugins.document.CommitQueue.afterTrunkCommit(CommitQueue.java:127)
> - locked <0x0000000781890788> (a
> org.apache.jackrabbit.oak.plugins.document.CommitQueue)
> at
> org.apache.jackrabbit.oak.plugins.document.CommitQueue.done(CommitQueue.java:83)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.done(DocumentNodeStore.java:637)
> {noformat}
> To avoid blocking the foreground thread, one solution is to store all data in
> a separate thread. If there is too much data added, then some of the data is
> not stored. If possible, the data that was not referenced a lot, and / or old
> revisions of documents (if new revisions are available).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
