[
https://issues.apache.org/jira/browse/SOLR-11702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16283455#comment-16283455
]
Mano Kovacs edited comment on SOLR-11702 at 12/8/17 12:31 PM:
--------------------------------------------------------------
Really like this approach, [~caomanhdat]. Not just a cleaner and more robust
approach, but I believe it could be an alternative solution for the problems
that motivates SOLR-7065 and SOLR-7034. Correct me if I am wrong, but replica
could become leader, regardless of their previous state or the number of
replicas participating, as their (and others) term number would explicitly say
if they are in sync or behind. Is my assumption correct?
was (Author: manokovacs):
Really like this approach, [~caomanhdat]. Not just a cleaner and more robust
approach, but I believe it could be an alternative solution for the problems
that motivates SOLR-7065. Correct me if I am wrong, but replica could become
leader, regardless of their previous state or the number of replicas
participating, as their (and others) term number would explicitly say if they
are in sync or behind. Is my assumption correct?
> Redesign current LIR implementation
> -----------------------------------
>
> Key: SOLR-11702
> URL: https://issues.apache.org/jira/browse/SOLR-11702
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Cao Manh Dat
> Assignee: Cao Manh Dat
> Attachments: SOLR-11702.patch
>
>
> I recently looked into some problem related to racing between LIR and
> Recovering. I would like to propose a totally new approach to solve SOLR-5495
> problem because fixing current implementation by a bandage will lead us to
> other problems (we can not prove the correctness of the implementation).
> Feel free to give comments/thoughts about this new scheme.
> https://docs.google.com/document/d/1dM2GKMULsS45ZMuvtztVnM2m3fdUeRYNCyJorIIisEo/edit?usp=sharing
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
