[
https://issues.apache.org/jira/browse/SOLR-8030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15204209#comment-15204209
]
David Smiley commented on SOLR-8030:
------------------------------------
I suppose one argument _against_ any change here is that the the current
behavior allows one to subclass Solr's default processors for whatever custom
purpose and also to perform some logic that only happens during PeerSync
(detectable by looking at the "flags" in the command to check for
UpdateCommand.PEER_SYNC bit). If we change to hard-code DistributedURP &
RunURP we lose that ability. I haven't had the need for such customizations,
granted, but I'm now less confident a change is needed. If we wind up making
no changes, then somehow we should make it clearer (docs) that you shouldn't be
setting default="true" on your URP chain unless you understand what you're
doing, since most likely the user should simply name the chain and use the
update.chain param. I had thought of these paths as equivalent but I learned
the hard way that they are different. It's an insidious problem because it
only bites you in failure situations (when PeerSync is used).
> 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.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]
