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/03/30 00:20:00 UTC
[jira] [Updated] (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:all-tabpanel ]
Jason Gerlowski updated SOLR-16725:
-----------------------------------
Description:
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) :
"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"},
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.
was:
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 :
"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”},
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) :
"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"},
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.
> 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
> Security Level: Public(Default Security Level. Issues are Public)
> 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) :
> "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"},
>
> 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