[
https://issues.apache.org/jira/browse/SOLR-9906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15787382#comment-15787382
]
Noble Paul commented on SOLR-9906:
----------------------------------
{{Thread.sleep(3000)}} in {{PeerSyncReplicationTest.forceNodeFailures}} need to
go. uncoditional waits are pretty bad
> 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-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]
