[
https://issues.apache.org/jira/browse/SOLR-6249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151861#comment-14151861
]
Mark Miller commented on SOLR-6249:
-----------------------------------
bq. The last param says to retry on connection loss. Do you think we need to do
more than this?
Again, ZooKeeper 101.
You can lose the ZK connection generally in two ways:
* ConnectionLoss
* SessionExpiration
When you lose the connection due to ConnectionLoss, all the Watches remain. You
have a couple choices - you can retry and hope the connection is reestablished,
or do something else (see the leader election algorithm for an example of
needing to do something else). Usually, you want to retry until you get a
session expiration. That is what passing true as the final param does for you -
it handles ConnectionLoss in the way you want to handle it 99% of the time.
SessionExpiration means the connection was lost for too long. Watches do not
span sessions. In this case, when you reconnect to ZooKeeper, it's pretty use
case specific how you need to handle things, but at a minimum, it usually means
re-creating any watches.
> 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]
