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

Tomek Rękawek commented on OAK-2106:
------------------------------------

I'll continue work on this. Current state can be found on [my 
github|https://github.com/trekawek/jackrabbit-oak/tree/OAK-2106]. I've finished 
a [draft of the replication lag 
estimator|https://github.com/trekawek/jackrabbit-oak/blob/OAK-2106/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/mongo/ReplicationLagEstimator.java],
 now we should decide in which cases it can be used.

I asked [~catholicon] about the "trickier" case when the change is done 
locally. He meant following situation: 

1. There's a branch.
2. We want to read the document xyz, belonging to this branch, modified in 12:10
3. xyz can be found in cache, with the modification date 12:00 (as the cache 
doesn't reflect branch changes).
4. Safe time for secondaries is 12:05 (>12:00).
5. We read the document from secondary and get an old version.

So, basically we shouldn't ask the secondary instance for a document belonging 
to a branch.

> Optimize reads from secondaries
> -------------------------------
>
>                 Key: OAK-2106
>                 URL: https://issues.apache.org/jira/browse/OAK-2106
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core, mongomk
>            Reporter: Marcel Reutegger
>            Assignee: Marcel Reutegger
>              Labels: performance, scalability
>
> OAK-1645 introduced support for reads from secondaries under certain
> conditions. The current implementation checks the _lastRev on a potentially
> cached parent document and reads from a secondary if it has not been
> modified in the last 6 hours. This timespan is somewhat arbitrary but
> reflects the assumption that the replication lag of a secondary shouldn't
> be more than 6 hours.
> This logic should be optimized to take the actual replication lag into
> account. MongoDB provides information about the replication lag with
> the command rs.status().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to