From oak-issues-return-39012-apmail-jackrabbit-oak-issues-archive=jackrabbit.apache.org@jackrabbit.apache.org Wed Oct 26 10:42:58 2016 Return-Path: X-Original-To: apmail-jackrabbit-oak-issues-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-oak-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A74BD195DA for ; Wed, 26 Oct 2016 10:42:58 +0000 (UTC) Received: (qmail 54576 invoked by uid 500); 26 Oct 2016 10:42:58 -0000 Delivered-To: apmail-jackrabbit-oak-issues-archive@jackrabbit.apache.org Received: (qmail 54549 invoked by uid 500); 26 Oct 2016 10:42:58 -0000 Mailing-List: contact oak-issues-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: oak-dev@jackrabbit.apache.org Delivered-To: mailing list oak-issues@jackrabbit.apache.org Received: (qmail 54538 invoked by uid 99); 26 Oct 2016 10:42:58 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 26 Oct 2016 10:42:58 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 5A2502C1F56 for ; Wed, 26 Oct 2016 10:42:58 +0000 (UTC) Date: Wed, 26 Oct 2016 10:42:58 +0000 (UTC) From: =?utf-8?Q?Tomek_R=C4=99kawek_=28JIRA=29?= To: oak-issues@jackrabbit.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (OAK-4882) Bottleneck in the asynchronous persistent cache MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/OAK-4882?page=3Dcom.atlassian.j= ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D156081= 12#comment-15608112 ]=20 Tomek R=C4=99kawek commented on OAK-4882: ------------------------------------ [~mmarth]: bq. But the way you describe it, it seems that the file maintenance is actu= ally the problem (or rather the fact that maintenance blocks put operations= ). I thought that the pers-cache is a) append-only and b) uses rotating fil= es. If so, it seems possible to keep adding entries even while files get ro= tated or old files removed... That is my understanding of the initial cause of the OAK-2761. [~tmueller],= could you elaborate on the cause of hangs described in OAK-2761? The whole async queue idea was introduced to fix this very issue, so if it = can be fixed on the persistence layer level, it'd be even better. In the me= antime, I'll carry on with the async queue work. It's optional (the async q= ueue is disabled by default and can be enabled via system property), so we = can try to tackle the issue from two sides. [~chetanm]: bq. We can improve a bit here by applying some heuristics Thanks for the ideas. I submitted a draft patch. The heuristics have been p= ut into {{NodeCache#qualifiesToPersist()}}. > 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=C4=99kawek > Assignee: Tomek R=C4=99kawek > Fix For: 1.6 > > Attachments: OAK-4882.patch > > > The class responsible for accepting new cache operations which will be ha= ndled asynchronously is [CacheActionDispatcher|https://github.com/apache/ja= ckrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/pl= ugins/document/persistentCache/async/CacheActionDispatcher.java]. In case o= f a high load, when the queue is full (=3D1024 entries), the [add()|https:/= /github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apa= che/jackrabbit/oak/plugins/document/persistentCache/async/CacheActionDispat= cher.java#L86] method removes the oldest 256 entries. However, we can't aff= ord losing the updates (as it may result in having stale entries in the cac= he), so all the removed entries are compacted into one big invalidate actio= n. > The compaction action ([CacheActionDispatcher#cleanTheQueue|https://githu= b.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/ja= ckrabbit/oak/plugins/document/persistentCache/async/CacheActionDispatcher.j= ava#L97]) still holds the lock taken in add() method, so threads which trie= s 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)