[
https://issues.apache.org/jira/browse/SOLR-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14097834#comment-14097834
]
Timothy Potter commented on SOLR-6249:
--------------------------------------
bq. the time it takes to reload the schema can vary by hundreds of milliseconds
Ok, makes sense ... not sure what to do about it ... polling across all
replicas seems sub-optimal as well (not to mention it's expensive to even
collect that information where there are many collections) ... maybe a happy
medium is to check all replicas in the same collection only?
bq. But that's the current situation, right?
Close, but with one main difference: if the update fails on one of the replicas
(but succeeds on others), the one experiencing the failure still remains
"active" and serves requests, i.e. there is no code that actively puts this
core into the down state, that will need to be added.
bq. a schema update that fails everywhere doesn't bring a collection down.
If it fails on the core that accepts the API request, it won't get written to
ZK (thus leaving the other replicas un-affected). I hope that's how it already
works but haven't tested that yet.
bq. Do we need to support that? It seems like an anti-pattern to me;
I think we do. If you don't want collections sharing configuration, why set it
up that way when you create the collections? In other words, if you create two
collections and re-use the same configuration, wouldn't you expect updates to
propagate to both? It think it is a pretty common thing to share configuration
across collections -- why do you think this is an anti-pattern?
> Schema API changes return success before all cores are updated
> --------------------------------------------------------------
>
> Key: SOLR-6249
> URL: https://issues.apache.org/jira/browse/SOLR-6249
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis, SolrCloud
> Reporter: Gregory Chanan
>
> See SOLR-6137 for more details.
> The basic issue is that Schema API changes return success when the first core
> is updated, but other cores asynchronously read the updated schema from
> ZooKeeper.
> So a client application could make a Schema API change and then index some
> documents based on the new schema that may fail on other nodes.
> Possible fixes:
> 1) Make the Schema API calls synchronous
> 2) Give the client some ability to track the state of the schema. They can
> already do this to a certain extent by checking the Schema API on all the
> replicas and verifying that the field has been added, though this is pretty
> cumbersome. Maybe it makes more sense to do this sort of thing on the
> collection level, i.e. Schema API changes return the zk version to the
> client. We add an API to return the current zk version. On a replica, if
> the zk version is >= the version the client has, the client knows that
> replica has at least seen the schema change. We could also provide an API to
> do the distribution and checking across the different replicas of the
> collection so that clients don't need ot do that themselves.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
