[
https://issues.apache.org/jira/browse/SOLR-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Potter updated SOLR-6249:
---------------------------------
Attachment: SOLR-6249.patch
Took a slightly different approach when waiting to see changes applied across
all replicas after discussing this issue with [~noble.paul]. Essentially,
instead of polling each replica until their zk schema version matches the
expected, I'm now sending a GET request like:
{{/schema/zkversion?refreshIfBelowVersion=N}} where N=expected version after
saving the updates to ZooKeeper. This tells the replica to proactively refresh
the schema if its current version is less than the value of the
refreshIfBelowVersion parameter. Of course in a healthy cluster, the watcher on
the managed-schema znode will likely fire long before this request comes in,
which is why the refreshIfBelowVersion parameter is needed as we don't want to
hit ZooKeeper more than necessary. This approach also blocks while the schema
is being refreshed so we're not having to send multiple network requests to
poll for the version.
Moreover, if the refresh fails, then likely that replica's ZooKeeper session
has expired or something bad like that so that core will go down and need to
recover.
One thing to note here is that technically a GET request can make changes (if
the refresh fires) which breaks pure REST principles. So I can easily move the
refresh stuff out to a separate endpoint but it seemed more intuitive to just
hang this off of the {{/schema/zkversion}} endpoint to me. In other words, a
conditional PUT seemed just as ugly to me in this case.
> 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: [email protected]
For additional commands, e-mail: [email protected]
