[
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
