[
https://issues.apache.org/jira/browse/SOLR-14245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17346847#comment-17346847
]
Ishan Chattopadhyaya commented on SOLR-14245:
---------------------------------------------
{quote}incidentally, the bug that causes {{node_name: null}} is likely related
to a buggy roundtrip conversion between ReplicaInfo <-> Replica... and guess
who added ReplicaInfo?).
{quote}
Are you suggesting that just because someone introduced a bug, we should screw
over the users? Consider the FORCELEADER thing we built for the leaderless
shard situation. Instead of preventing all nodes and clients from working for
that cluster (because a leader is essential, isn't it?), we built a mechanism
to let the user correct that mistake manually. Instead, your hammer approach in
this issue was to slam the door on the face of the user just because there
exists a bug in the system. This is the "attitude" that I'm criticising, not
attacking you personally.
> Validate Replica / ReplicaInfo on creation
> ------------------------------------------
>
> Key: SOLR-14245
> URL: https://issues.apache.org/jira/browse/SOLR-14245
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
> Priority: Minor
> Fix For: 8.5
>
>
> Replica / ReplicaInfo should be immutable and their fields should be
> validated on creation.
> Some users reported that very rarely during a failed collection CREATE or
> DELETE, or when the Overseer task queue becomes corrupted, Solr may write to
> ZK incomplete replica infos (eg. node_name = null).
> This problem is difficult to reproduce but we should add safeguards anyway to
> prevent writing such corrupted replica info to ZK.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
