[
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
(v6.3.4#6332)
