[
https://issues.apache.org/jira/browse/SOLR-4202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13535061#comment-13535061
]
Yonik Seeley commented on SOLR-4202:
------------------------------------
Tricky.... it's hard to figure out of this will increase fail scenarios.
What if we lose connectivity, and miss a few updates.
Then we get back connectivity, accept a bunch of updates (more than the window
of recent updates we keep track of), then reconnect to ZK.
We do a recovery, compare recent updates, and conclude that we are up to date.
Aside: I thought the leader requested a replica to go into recovery if it
returns a failure from an update?
> Relax rules around accepting updates when not connected to zookeeper.
> ---------------------------------------------------------------------
>
> Key: SOLR-4202
> URL: https://issues.apache.org/jira/browse/SOLR-4202
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: Mark Miller
> Assignee: Mark Miller
> Priority: Minor
> Fix For: 4.1, 5.0
>
>
> We are pretty tight about this currently - I think it might be a bit nicer if
> we relax a little.
> Right now, as soon we realize we cannot talk to zookeeper, we stop accepting
> updates in all cases.
> I think it might be better if we change that a bit for a non leader. It might
> be nicer if it would still accept updates from the leader, but fail them.
> This way, there is some chance that if the problem was simply a connection
> loss with zookeeper, when the leader asks the replica to recover because it
> failed the update, it's more likely to just take a peersync to catch up.
> Thoughts?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
