[
https://issues.apache.org/jira/browse/SOLR-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14790640#comment-14790640
]
Hoss Man commented on SOLR-8030:
--------------------------------
bq. It seems that log entries are added at the end of the update processor
chain and replayed from the beginning of the default processor chain.
bq. Why the log replay does not use the RunUpdateProcessor directly, instead of
the full update chain ?
Unless i'm remembering incorrectly, replaying directly to RunUpdateProcessor
would also be a mistake -- isn't DistributedUpdateProcessor (on the leader)
what is currently writting to the tlog? ... in order to ensure consistent
processors, the replay should be resumed by DistributedUpdateProcessor _of the
same chain_
i thought was already how it worked (DistributedUpdateProcessor handling log
replay) ... i thought this bug was just pointing out that the default chain was
always used for the replay, not whatever chain was involved in the original
command? (if not then the problem is bigger then initially discussed)
> 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
>
> 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]
