[
https://issues.apache.org/jira/browse/SOLR-16725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729813#comment-17729813
]
Indumathy Rajagopalan commented on SOLR-16725:
----------------------------------------------
[~senthh] : Adding to [~gerlowskija] 's point , my main concern is any
existing tool/automation on the client side that does case sensitive decoding
(where we define the field to be decoded ) from the output might break. We
have had a few instances where some of our tools failed while parsing the
CLUSTERSTATUS output soon after we restored a collection with RESTORE API.
> 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-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
