[jira] [Created] (SOLR-7932) Solr replication relies on timestamps to sync across machines

["Ramkumar Aiyengar (JIRA)" <ji...@apache.org>]

Ramkumar Aiyengar created SOLR-7932:
---------------------------------------

             Summary: 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


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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org