You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "Chris M. Hostetter (Jira)" <ji...@apache.org> on 2023/04/18 00:23:00 UTC

[jira] [Created] (SOLR-16751) ClusterState.collectionFromObjects() stores copy of shards in DocCollection.getProperties()

Chris M. Hostetter created SOLR-16751:
-----------------------------------------

             Summary: ClusterState.collectionFromObjects() stores copy of shards in DocCollection.getProperties()
                 Key: SOLR-16751
                 URL: https://issues.apache.org/jira/browse/SOLR-16751
             Project: Solr
          Issue Type: Bug
      Security Level: Public (Default Security Level. Issues are Public)
            Reporter: Chris M. Hostetter


The way a {{DocCollection}} is created by {{ClusterState.collectionFromObjects()}} ( ie: {{ClusterState}} is read from a JSON payload – such as {{state.json}} ) a copy of the original {{"shards"}} mappings is left in the {{props}} argument (where it's carried around in {{DocCollection.getProperties()}} ) in addition to the (correct) {{slices}} argument (which is used to build {{DocCollection.getSlices()}} )

This is due to the following lines of code, which AFAICT should have been done in reverse order...
{code:java}
      props = new HashMap<>(objs);
      objs.remove(CollectionStateProps.SHARDS);
{code}
This bug seems to have existed for a while, but seems to have slipped under the radar since nothing has any reason to be looking for a {{"shards"}} key in {{DocCollection.getProperties()}} .

Recently however, noble committed 2ac7ed29563a33d9f9a31737996a1d4cfb0fca0d which changed the serialization logic for {{DocCollection}} to eliminate a temporary map...
{noformat}
-    LinkedHashMap<String, Object> all = CollectionUtil.newLinkedHashMap(slices.size() + 1);
-    all.putAll(propMap);
-    all.put(CollectionStateProps.SHARDS, slices);
-    jsonWriter.write(all);
+    jsonWriter.write(
+        (MapWriter)
+            ew -> {
+              propMap.forEach(ew.getBiConsumer());
+              ew.put(CollectionStateProps.SHARDS, slices);
+            });
{noformat}
... so now, instead of an {{all}} Map where the {{"shards"}} key from {{propMap}} being (correctly) overridden by {{slices}} and then serialized, now the JSON output contains two entries with the {{"shards"}} key.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org