[
https://issues.apache.org/jira/browse/SOLR-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14900359#comment-14900359
]
Ludovic Boutros commented on SOLR-8030:
---------------------------------------
I will update the test in order to control pre-distributed processors (buffered
updates during recovery).
I will also rename the processor which locks the replay with a more explicit
name.
I propose to add one or two flags to the command status to be able to detect
already processed update commands (before and after distribution).
They should be set in the RunUpdateProcessor and in the
DistributedUpdateProcessor.
For buffered updates, the replay should start processing update from the
DistributedUpdateProcessor.
For the other updates, the replay should only use the RunUpdateProcessor.
For the update chain, I think the name could be stored in the tlog and reused
during replay (With perhaps the last chain cached to prevent the search in the
update chain map...).
> Transaction log does not store the update chain used for updates
> ----------------------------------------------------------------
>
> Key: SOLR-8030
> URL: https://issues.apache.org/jira/browse/SOLR-8030
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Affects Versions: 5.3
> Reporter: Ludovic Boutros
> Attachments: SOLR-8030-test.patch
>
>
> Transaction Log does not store the update chain used during updates.
> Therefore tLog uses the default update chain during log replay.
> If we implement custom update logic with multiple update chains, the log
> replay could break this logic.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
