[
https://issues.apache.org/jira/browse/SOLR-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14097783#comment-14097783
]
Steve Rowe commented on SOLR-6249:
----------------------------------
bq. The idea here is that if 1 other replica has the update, then likely all
do, which is a little loose but this is just to alleviate the need for a client
application to add any polling code in the client side.
Even when all cores hosting shards in a collection are on the same box, as in
unit testing, and even though all cores receive schema change notifications
within single-digit milliseconds of each other, the time it takes to reload the
schema can vary by hundreds of milliseconds.
bq. Seems to me like less coordination here is best? In other words, instead of
the core that accepts the update request worrying about all the other cores
that are going to see the update, it just assumes it will be successful.
But that's the current situation, right?
bq. If any of the remote cores fail in processing the update, then they mark
themselves as "down". This seems to solve the root of the problem raised by
this ticket, namely a replica using the wrong version of a managed schema.
This sounds like a good idea, though we'll have to be careful that a schema
update that fails everywhere doesn't bring a collection down.
As I mentioned above, though, the root of the problem is about versioning
differences that result from varying schema load time.
> 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]
