[
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) :
{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.
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 :
{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.
> 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) :
> {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: [email protected]
For additional commands, e-mail: [email protected]
