You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2020/04/13 02:48:00 UTC
[jira] [Commented] (SOLR-9906) Use better check to validate if node
recovered via PeerSync or Replication
[ https://issues.apache.org/jira/browse/SOLR-9906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17081996#comment-17081996 ]
ASF subversion and git services commented on SOLR-9906:
-------------------------------------------------------
Commit 13f19f65559290a860df84fa1b5ac2db903b27ec in lucene-solr's branch refs/heads/master from Shalin Shekhar Mangar
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=13f19f6 ]
SOLR-9906: SolrjNamedThreadFactory is deprecated in favor of SolrNamedThreadFactory. DefaultSolrThreadFactory is removed from solr-core in favor of SolrNamedThreadFactory in solrj package and all solr-core classes now use SolrNamedThreadFactory
> 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
> 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
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org