lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Smiley (JIRA)" <>
Subject [jira] [Commented] (SOLR-8030) Transaction log does not store the update chain used for updates
Date Mon, 21 Mar 2016 13:54:25 GMT


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:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message