Chris M. Hostetter created SOLR-18435:
-----------------------------------------
Summary: CloudSolrClient and implicit assumptions about
Set<String> liveNodes
Key: SOLR-18435
URL: https://issues.apache.org/jira/browse/SOLR-18435
Project: Solr
Issue Type: Sub-task
Reporter: Chris M. Hostetter
(See parent Jira for larger context: SOLR-18433)
Currently, if you send a {{CollectionAdminRequest}} via {{CloudSolrClient}} the
resulting LBSolrClient request tries nodes in order according to the iterator
of the {{Set<String> liveNodes}} – which for {{ZKClusterStateProvider}} is a
{{TreeSet}} (but this is undocumented) and for {{BaseHttpClusterStateProvider}}
is whatever the JVM decides to return from a call of {{Set.copyOf(...)}} (where
the source collection is a {{List<String>}} returned over the wire from a
remote solr instance, who was itself iterating over a {{TreeSet}} from
{{ZKClusterStateProvider}})
This means that a {{CloudSolrClient}} using {{ZKClusterStateProvider}} the
recommendation for people who disable overseer to try and send collection admin
requests to a consistent node is _accidentally_ happening for them
automatically – but I have no idea if it's working for people using
{{BaseHttpClusterStateProvider}}
----
we should make this behavior more consistent, and more intentional:
* {{BaseHttpClusterStateProvider}} should probably explicitly use a
{{TreeSet<String>}} as well
* Uses of {{liveNodes}} in {{CloudSolrClient}} should probably have at least a
comment about the implicit assumption that {{liveNodes}} has a consistent
iterator, but ideally it should be copied into an explicitly sorted
datastructure
** either that: or update all the liveNodes APIs to use {{SortedSet<String>}}
explicitly
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
