[ https://issues.apache.org/jira/browse/SOLR-8263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Renaud Delbru updated SOLR-8263: -------------------------------- Attachment: SOLR-8263-trunk-2.patch A new version of the patch (this replaces the previous one) which includes a fix related to the write lock. In the previous patch, the write lock was removed accidentally while re-initialising the update log with the new set of tlog files (the init method was creating a new instance of the VersionInfo). As a consequence there was a small time frame where updates were lost (a batch of documents were missed in 1 over 10 runs). The fix introduces a new init method that preserves the original VersionInfo instance and therefore preserves the write lock. I have run the test 50 times without seeing anymore the issue. > Tlog replication could interfere with the replay of buffered updates > -------------------------------------------------------------------- > > Key: SOLR-8263 > URL: https://issues.apache.org/jira/browse/SOLR-8263 > Project: Solr > Issue Type: Sub-task > Reporter: Renaud Delbru > Assignee: Erick Erickson > Attachments: SOLR-8263-trunk-1.patch, SOLR-8263-trunk-2.patch > > > The current implementation of the tlog replication might interfere with the > replay of the buffered updates. The current tlog replication works as follow: > 1) Fetch the the tlog files from the master > 2) reset the update log before switching the tlog directory > 3) switch the tlog directory and re-initialise the update log with the new > directory. > Currently there is no logic to keep "buffered updates" while resetting and > reinitializing the update log. -- 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