RE: Restored collection cluster status rendering some values as Long (as opposed to String for other collections)

2020-06-24 Thread Aliaksandr Asiptsou
Sorry I forgot to mention: we use Solr 8.3.1

Best regards,
Aliaksandr Asiptsou
From: Aliaksandr Asiptsou
Sent: Wednesday, June 24, 2020 12:44 AM
To: solr-user@lucene.apache.org
Subject: Restored collection cluster status rendering some values as Long (as 
opposed to String for other collections)

Hello Solr experts,

Our team noticed the below behavior:

1. A collection is restored from a backup, and a replication factor is 
specified within the restore command:

/solr/admin/collections?action=RESTORE=backup_name=/backups/solr=collection_name=config_name=1=1

2. Collection restored successfully, but looking into cluster status we see 
several values are rendered as Long for this particular collection:

/solr/admin/collections?action=clusterstatus=xml

0
1
1
false
1
0
138

Whereas for all the other collections pullReplicas, replicationFactor, 
nrtReplicas and tlogReplicas are Strings.

Please advise whether it is known and expected or it needs to be fixed (if so, 
is there a Jira ticket already for this or should we create one)?

Best regards,
Aliaksandr Asiptsou


Restored collection cluster status rendering some values as Long (as opposed to String for other collections)

2020-06-23 Thread Aliaksandr Asiptsou
Hello Solr experts,

Our team noticed the below behavior:

1. A collection is restored from a backup, and a replication factor is 
specified within the restore command:

/solr/admin/collections?action=RESTORE=backup_name=/backups/solr=collection_name=config_name=1=1

2. Collection restored successfully, but looking into cluster status we see 
several values are rendered as Long for this particular collection:

/solr/admin/collections?action=clusterstatus=xml

0
1
1
false
1
0
138

Whereas for all the other collections pullReplicas, replicationFactor, 
nrtReplicas and tlogReplicas are Strings.

Please advise whether it is known and expected or it needs to be fixed (if so, 
is there a Jira ticket already for this or should we create one)?

Best regards,
Aliaksandr Asiptsou