[
https://issues.apache.org/jira/browse/OAK-4528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15432784#comment-15432784
]
Marcel Reutegger commented on OAK-4528:
---------------------------------------
Added a test to trunk to assess the performance improvement when the
observation queue fills up and after a while is given time to recover:
http://svn.apache.org/r1757367
ObservationQueueTest sets up a two node cluster with sessions that read, write
and observe. The default setup has 10 sessions for each of those operations.
The test writes for 10 minutes and the queue fills up to 1000 entries after
about two minutes on my machine. With Oak trunk the system is able to clear the
queue within one minute and 40 seconds on my machine after the write load
stops. Without this improvement (on 1.4) the queue is empty after roughly one
hour and 20 minutes.
> diff calculation in DocumentNodeStore should try to re-use journal info on
> diff cache miss
> ------------------------------------------------------------------------------------------
>
> Key: OAK-4528
> URL: https://issues.apache.org/jira/browse/OAK-4528
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, documentmk
> Reporter: Vikas Saurabh
> Assignee: Marcel Reutegger
> Priority: Minor
> Labels: observation, resilience
> Fix For: 1.6, 1.5.6
>
>
> Currently, diff information is filled into caches actively (local commits
> pushed in local_diff, externally read changes pushed into memory_diff). At
> the time of event processing though, the entries could have already been
> evicted.
> In that case, we fall back to computing diff by comparing 2 node-states which
> becomes more and more expensive (and eventually fairly non-recoverable
> leading to OAK-2683).
> To improve the situation somewhat, we can probably try to consult journal
> entries to read a smaller-superset of changed paths before falling down to
> comparison.
> /cc [~mreutegg], [~chetanm], [~egli]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
