[
https://issues.apache.org/jira/browse/SOLR-11469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16217195#comment-16217195
]
Hoss Man commented on SOLR-11469:
---------------------------------
bq. We will have same replica names for each collection. ( This satisfy current
logic of Assign.buildCoreNodeName )
Hmmm... i'm -0 having the test make these assumptions. Fundementally this is
the same problem the test had before: it makes assumptions about the lower
level implementation of how/when coreNodeMakes will be assigned that the client
code used in the test doesn't have any control over -- and doesn't directly
validate. if/when the implementation changes the test _may_ start failing in
unpredictable ways.
Can we please at least add some sanity check assertions to this test that will
look at the clusterstate and fail with a clear error message if the
audo-assigned coreNodeNames don't match the expectations of the test?
> LeaderElectionContextKeyTest has flawed logic: 50% of the time it checks the
> wrong shard's elections
> ----------------------------------------------------------------------------------------------------
>
> Key: SOLR-11469
> URL: https://issues.apache.org/jira/browse/SOLR-11469
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Assignee: Cao Manh Dat
> Fix For: 7.2, master (8.0)
>
> Attachments: SOLR-11469.patch, SOLR-11469.patch,
> SOLR-11469_incomplete_and_broken.patch
>
>
> LeaderElectionContextKeyTest is very flaky -- and on millers beastit reports
> it shows a suspiciously close to "50%" failure rate.
> Digging into the test i realized that it creates a 2 shard index, then picks
> "a leader" to kill (arbitrarily) and then asserts that the leader election
> nodes for *shard1* are affected ... so ~50% of the time it kills the shard2
> leader and then fails because it doesn't see an election in shard1.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
