jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vikas Saurabh (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (OAK-2106) Optimize reads from secondaries
Date Sun, 05 Jul 2015 21:05:04 GMT

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

Vikas Saurabh edited comment on OAK-2106 at 7/5/15 9:04 PM:
------------------------------------------------------------

[~mreutegg], I might be missing something, but
bq. It might be better to only make those external changes visible when they appear on a nearer
secondary. Subsequent reads could then be performed on that secondary as well.
seems to imply that {{nearest}} read preference would always pick the same secondary (or primary
if that's nearest) -- which I don't think is true. So, I think reading simply reading external
rev with {{nearest}} secondary might not cut it.


was (Author: catholicon):
[~mreutegg], I might be missing something, but
bq. It might be better to only make those external changes visible when they appear on a nearer
secondary. Subsequent reads could then be performed on that secondary as well.
seems to imply that {{nearest}} read preference would always pick the same secondary -- which
I don't think is true. So, I think reading simply reading external rev with {{nearest}} secondary
might not cut it.

> 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
>             Fix For: 1.3.5
>
>
> 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)

Mime
View raw message