Hi,

Let me give a bit of background first. I am looking at OAK-2106[0] -
using replication status to have a stronger bound of replication lag
of secondaries and hence be more informed while providing
ReadPreference[1].

---- Background ----
While assessing if secondaries would be useful to read a document, the
current logic looks for the parent document from cache - hence, if
found, the parent status is up-to-date as far as last backgroundRead
is done. Then, the parent is checked if it was modified within
replication lag window.
With the assumption that backgroundRead would have happened within
last 6 hours, the current hard-code value of replication lag suffices.
With replication lag being pulled from replication status, we'd need
to use min(lastBackgroundReadTime, currTime-maxReplicationLag).

There's an issue (still unresolved) for Mongo Java driver (JAVA-805)
which is about observing such status. Until, that is resolved, we'd
need to poll for replication lag using replSetGetStatus [3] command.

Since, there's a fairly tight coupling between usefulness of how
recent is the value replication lag and how frequently are we able to
do backgroundReads, it feels that we can tie up polling for
replication lag along with backgroundReads.
---- /Background ----

While replication lag calculation is entirely a domain of
MongoDocumentStore, but I'd not want to have a new thread to just keep
polling for replication lag. Otoh, currently, there's no way for
MongoDocStore to know when backgroundReads happened.

It'd great if DocumentNodeStore can notify the underlying store with
something like 'backgroundReadDone'. It can remain no-op for all the
stores and MongoDocStore can utilize this as a way to fetch
replication status.

Does it make sense to have such a mechanism?

Thanks,
Vikas

[0]: https://issues.apache.org/jira/browse/OAK-2106
[1]: http://docs.mongodb.org/manual/core/read-preference/
[2]: https://jira.mongodb.org/browse/JAVA-805
[3]: 
http://docs.mongodb.org/manual/reference/command/replSetGetStatus/#dbcmd.replSetGetStatus

Reply via email to