[
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_reconnect.patch
Here's an additional patch that addresses the ZkIndexSchemaReader watcher
reconnect issue discussed in the comments.
[~noble.paul] please take a quick look. I know you recommended integrating this
into ZkStateReader, but I did it in ZkController instead because on the
server-side, ZkStateReader actually uses the OnReconnect implementation in
ZkController. The basic idea here is that any component that sets up a watcher
can register an OnReconnect listener with ZkController to be called after a
reconnected Zk session; see the command method in ZkIndexSchemaReader for an
example.
If this looks acceptable to everyone watching, I'll commit and then backport to
branch_5x
> 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,
> SOLR-6249_reconnect.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
