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-4124) Persistent cache: consider using callstack blocking
Date Tue, 15 Mar 2016 10:11:33 GMT

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

Tomek Rękawek commented on OAK-4124:

With this patch, we'll only block the callers if the load is high and the queue becomes full
(eg. there's many put() operations from a single or multiple callers). If the load is low
again, the put()s will be done asynchronously.

As far as I understand, the asynchronous put() were introduced to avoid a situation in which
we have a single put() that takes a lot of time (because there's some underneath maintenance
going on). In this case, all the other concurrent put()s should place their payloads into
the queue and return the control to the caller thread.

So, the cache behaviour will be as follows:

1. low/normal load -> consumer faster than producers -> queue is not full -> put()s
done asynchronously, a single long put() won't block any threads
2. high load -> consumer slower than producers -> queue is full -> put()s done synchronously,
to avoid flushing the queue and losing cache values

Ad. 1 - this is the case described in OAK-2761
Ad. 2 - this is the case from OAK-4123

> Persistent cache: consider using callstack blocking
> ---------------------------------------------------
>                 Key: OAK-4124
>                 URL: https://issues.apache.org/jira/browse/OAK-4124
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: cache
>            Reporter: Tomek Rękawek
>              Labels: performance
>             Fix For: 1.6
>         Attachments: OAK-4124.patch
> In the current implementation of the asynchronous add operation in persistence cache,
data are added to a queue and if the queue is full, the oldest entries are removed (see OAK-2761).
> It may deteriorate the system performance in some cases (OAK-4123). Let's consider a
different approach, in which we block the caller thread in case the queue is full.

This message was sent by Atlassian JIRA

View raw message