You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "Jason Gerlowski (Jira)" <ji...@apache.org> on 2023/06/06 13:30:00 UTC
[jira] [Commented] (SOLR-16725) CLUSTERSTATUS API output has inconsistent data types for a few values against the newly restored collection
[ https://issues.apache.org/jira/browse/SOLR-16725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729738#comment-17729738 ]
Jason Gerlowski commented on SOLR-16725:
----------------------------------------
Hopefully [~indurajagopalan] can chime in to correct me, but my read was that the impact here is mostly client-side. Clients that make CLUSTERSTATUS calls and attempt to parse the response need to write code to check for either String or numeric JSON values, or else risk ClassCastExceptions or some similar issue.
I imagine Solr makes these calls internally, but it's unclear whether it's affected on the server side. (Maybe it never tries to read the particular properties that cause problems? 🤷)
Anyway, I'll let Indumathy chime in here to clarify rather than trying to guess!
> CLUSTERSTATUS API output has inconsistent data types for a few values against the newly restored collection
> -----------------------------------------------------------------------------------------------------------
>
> Key: SOLR-16725
> URL: https://issues.apache.org/jira/browse/SOLR-16725
> Project: Solr
> Issue Type: Bug
> Reporter: Indumathy Rajagopalan
> Priority: Critical
>
> h2. *Description*
>
> Once a new collection is restored with admin/collection?action=RESTORE , CLUSTERSTATUS API output has inconsistent data types for a few values against the newly restored collection.
>
> {*}Example{*}:
>
> Snippet of CLUSTERSTATUS Command output for a collection created with explicit admin/collection?ACTION=CREATE command :
> {code}
> "cluster":{
> "collections":{
> "collectionname":{
> "pullReplicas":"0”, <———— value is presented as a string
> "replicationFactor":"3”, <———— value is presented as a string
> "shards”:{ per shard info … },
> "router":{"name":"compositeId"},
> "maxShardsPerNode":"1",
> "autoAddReplicas":"false",
> "nrtReplicas":"3",
> "tlogReplicas":"0",
> "health":"GREEN",
> "znodeVersion":17,
> "configName”:”config”},
> {code}
>
> Snippet of CLUSTERSTATUS Command output for a collection created admin/collection?ACTION=RESTORE command (where the collection is created implicitly as a part of the RESTORE action) :
> {code}
> "restoredcollectionname":{
> "pullReplicas":0, <———— value is presented as an int
> "replicationFactor":3, <———— value is presented as an int
> "shards”:\{ per shard info … },
> "router":\{"name":"compositeId"},
> "maxShardsPerNode":3,
> "autoAddReplicas":"false",
> "nrtReplicas":3,
> "tlogReplicas":0,
> "health":"GREEN",
> "znodeVersion":13,
> "configName":"config1"},
> {code}
>
> Note the change in the data types for fields like pullReplicas , replicationFactor ( string vs integer) against different collections within the same cluster.
>
> The data type for the values need to be consistent across all the collections.
--
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