[
https://issues.apache.org/jira/browse/SOLR-9906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15824411#comment-15824411
]
Erick Erickson commented on SOLR-9906:
--------------------------------------
Beasting after this latest push succeeded 100 times out of 100. Prior it
failed for me 21/100 times.
> 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
> Assignee: Noble Paul
> Priority: Minor
> Fix For: 6.4
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
