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

Ramkumar Aiyengar updated SOLR-7932:
------------------------------------
    Attachment: SOLR-7932.patch

Attached is a patch to remove the use of versions. This however fails 
{{TestReplicationHandler}} tests, need to dig into that further..

> Solr replication relies on timestamps to sync across machines
> -------------------------------------------------------------
>
>                 Key: SOLR-7932
>                 URL: https://issues.apache.org/jira/browse/SOLR-7932
>             Project: Solr
>          Issue Type: Bug
>          Components: replication (java)
>            Reporter: Ramkumar Aiyengar
>         Attachments: SOLR-7932.patch
>
>
> Spinning off SOLR-7859, noticed there that wall time recorded as commit data 
> on a commit to check if replication needs to be done. In IndexFetcher, there 
> is this code:
> {code}
>       if (!forceReplication && 
> IndexDeletionPolicyWrapper.getCommitTimestamp(commit) == latestVersion) {
>         //master and slave are already in sync just return
>         LOG.info("Slave in sync with master.");
>         successfulInstall = true;
>         return true;
>       }
> {code}
> It appears as if we are checking wall times across machines to check if we 
> are in sync, this could go wrong.
> Once a decision is made to replicate, we do seem to use generations instead, 
> except for this place below checks both generations and timestamps to see if 
> a full copy is needed..
> {code}
>       // if the generation of master is older than that of the slave , it 
> means they are not compatible to be copied
>       // then a new index directory to be created and all the files need to 
> be copied
>       boolean isFullCopyNeeded = IndexDeletionPolicyWrapper
>           .getCommitTimestamp(commit) >= latestVersion
>           || commit.getGeneration() >= latestGeneration || forceReplication;
> {code}



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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to