[
https://issues.apache.org/jira/browse/SOLR-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14098098#comment-14098098
]
Gregory Chanan commented on SOLR-6249:
--------------------------------------
bq. I only have one little SolrCloud setup, but right now every one of the
collections that it has is using the same configuration set. I would expect
that if I update my schema, it would apply the changes to all my collections,
because I made the deliberate decision for them to share that configuration.
Can our instructions for SolrCloud easily result in a situation where a user
has multiple collections sharing a configuration, and is unaware of that fact?
The confusing thing for me was that the schema API calls are on the collection
(collectioName/schema), not the configuration. So, it looks like you are just
modifying the collection rather than the configuration, and surprising that
another collection was modified (i.e. it doesn't matter if I call
collection1/schema or collection2/schema if they use the same configuration).
I wouldn't have been surprised if the endpoint was on the configuration somehow
(not sure how that would work though). If you really understand how everything
works under the covers, I guess it makes sense.
I'm not sure how much this matters either. I guess the question is what we do
on failures and whether only the collection endpoint you modify has to succeed
or all of the collections that use the configuration have to succeed else we
run th failure code.
> 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]
