lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-9906) Use better check to validate if node recovered via PeerSync or Replication
Date Tue, 03 Jan 2017 18:55:58 GMT

    [ https://issues.apache.org/jira/browse/SOLR-9906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15795845#comment-15795845
] 

ASF subversion and git services commented on SOLR-9906:
-------------------------------------------------------

Commit 812070a77f483149e1d83b3d1bbc7ba80f0fd868 in lucene-solr's branch refs/heads/branch_6x
from [~noble.paul]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=812070a ]

SOLR-9906-Use better check to validate if node recovered via PeerSync or Replication


> Use better check to validate if node recovered via PeerSync or Replication
> --------------------------------------------------------------------------
>
>                 Key: SOLR-9906
>                 URL: https://issues.apache.org/jira/browse/SOLR-9906
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Pushkar Raste
>            Priority: Minor
>         Attachments: SOLR-9906.patch, SOLR-9906.patch, SOLR-PeerSyncVsReplicationTest.diff
>
>
> Tests {{LeaderFailureAfterFreshStartTest}} and {{PeerSyncReplicationTest}} currently
rely on number of requests made to the leader's replication handler to check if node recovered
via PeerSync or replication. This check is not very reliable and we have seen failures in
the past. 
> While tinkering with different way to write a better test I found [SOLR-9859|SOLR-9859].
Now that SOLR-9859 is fixed, here is idea for better way to distinguish recovery via PeerSync
vs Replication. 
> * For {{PeerSyncReplicationTest}}, if node successfully recovers via PeerSync, then file
{{replication.properties}} should not exist
> For {{LeaderFailureAfterFreshStartTest}}, if the freshly replicated node does not go
into replication recovery after the leader failure, contents {{replication.properties}} should
not change 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message