jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Reutegger (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (OAK-6087) Avoid reads from MongoDB primary
Date Wed, 23 May 2018 15:59:00 GMT

     [ https://issues.apache.org/jira/browse/OAK-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Marcel Reutegger resolved OAK-6087.
       Resolution: Fixed
    Fix Version/s: 1.9.3

Committed the most recent state of the feature branch to trunk: http://svn.apache.org/r1832110

Documentation is pending.

> Avoid reads from MongoDB primary
> --------------------------------
>                 Key: OAK-6087
>                 URL: https://issues.apache.org/jira/browse/OAK-6087
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: mongomk
>            Reporter: Marcel Reutegger
>            Assignee: Marcel Reutegger
>            Priority: Major
>              Labels: scalability
>             Fix For: 1.10, 1.9.3
>         Attachments: OAK-6087.patch
> With OAK-2106 Oak now attempts to read from a MongoDB secondary when it detects the requested
data is available on the secondary.
> When multiple Oak cluster nodes are deployed on a MongoDB replica set, many reads are
still directed to the primary. One of the reasons why this is seen in practice, are observers
and JCR event listeners that are triggered rather soon after a change happens and therefore
read recently modified documents. This makes it difficult for Oak to direct calls to a nearby
secondary, because changes may not yet be available there.
> A rather simple solution for the observers may be to delay processing of changes until
they are available on the near secondary.
> A more sophisticated solution discussed offline could hide the replica set entirely and
always read from the nearest secondary. Writes would obviously still go to the primary, but
only return when the write is available also on the nearest secondary. This guarantees that
any subsequent read is able to see the preceding write.

This message was sent by Atlassian JIRA

View raw message