lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mano Kovacs (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SOLR-11702) Redesign current LIR implementation
Date Fri, 08 Dec 2017 12:32:00 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message