[
https://issues.apache.org/jira/browse/SOLR-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151809#comment-14151809
]
Timothy Potter commented on SOLR-6249:
--------------------------------------
Ok, that makes sense but seems like a generic issue vs. specific to this class.
We could solve this specifically right now doing what you suggest but rather
than polluting ZkStateReader with utility methods for setting watchers, I think
we should have a generic watcher support class. ZkStateReader's job is to
handle collection state right? It's not some generic ZK utility class that the
rest of the code should use. There should be a ticket for refactoring any code
that sets a watcher to do it correctly, including ZkIndexSchemaReader, or is
this the only place in the code that doesn't set a watcher correctly?
> 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
> Assignee: Timothy Potter
> Attachments: SOLR-6249.patch, SOLR-6249.patch, SOLR-6249.patch
>
>
> 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.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
