[
https://issues.apache.org/jira/browse/SOLR-5015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13705610#comment-13705610
]
Daniel Collins commented on SOLR-5015:
--------------------------------------
If we are suggesting alternative formats, could I vote for something with a
little more detail?
{code:javascript}
"shards.info":[
{
"shardName": "shard2",
"servers":[
"207.237.114.232:8984/solr/collection1/",
"207.237.114.232:8986/solr/collection1/"
],
"numFound":2,
"maxScore":1.0,
"time":224
},
{
"shardName": "shard1",
"servers":[
"207.237.114.232:8983/solr/collection1/",
"207.237.114.232:8985/solr/collection1/"
],
"numFound":8,
"maxScore":1.0,
"time":898
}
]
{code}
The 2 important differences (for us) are that shards.info becomes an array
instead of an object with (non-obvious) keys, this seems a better fit
conceptually. And also, the list of servers becomes an array instead of a
string with some internal parsing required (separated by |).
Lastly, (though this could be a separate issue), it would be nice if
shards.info indicated *which* server out of the list it actually went to?
Currently the response indicates the results come from shard1 and shard2 and
which possible servers could have generated those responses. It would be nice
(for monitoring load and checking timings) to see which of these 2 servers
actually supplied the results for this query. We could use that to check
timing issues/load spikes on a particular replica of a shard.
I appreciate that shards.info pre-dates SolrCloud, and in that (Solr 3.x) world
the client dictated which servers to to go, but in the Cloud world, Solr can
load-balance itself, so it would be nice to see where it is sending requests
for monitoring purposes. Maybe we need a new cloud-aware parameter (e.g.
"replicas.info"), that wouldn't suffer any backward compatibility issues?
> shards.info should return the shard ID
> --------------------------------------
>
> Key: SOLR-5015
> URL: https://issues.apache.org/jira/browse/SOLR-5015
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud
> Reporter: Jack Krupansky
>
> Currently, the shards.info section of a SolrCloud query response uses "the |
> delimited list of equivalent servers" of the available servers for the shard
> keys in the response, rather than the shard IDs (names?.)
> My first preference would be for the shard IDs to be used for the shards.info
> keys, and then the list of servers could be a "servers" key value at the next
> level down in the response. But if compatibility is important, continue to
> use the server list as the keys for shards.info, and then add "shardID" or
> "shardName" as a key at the next level down in the response.
> For example, instead of:
> {code}
> "shards.info":{
>
> "207.237.114.232:8984/solr/collection1/|207.237.114.232:8986/solr/collection1/":{
> "numFound":2,
> "maxScore":1.0,
> "time":224},
>
> "207.237.114.232:8983/solr/collection1/|207.237.114.232:8985/solr/collection1/":{
> "numFound":8,
> "maxScore":1.0,
> "time":898}},
> {code}
> My first choice would be:
> {code}
> "shards.info":{
> "shard2": {
> "servers":
> "207.237.114.232:8984/solr/collection1/|207.237.114.232:8986/solr/collection1/",
> "numFound":2,
> "maxScore":1.0,
> "time":224},
> "shard1": {
> "servers":
> "207.237.114.232:8983/solr/collection1/|207.237.114.232:8985/solr/collection1/",
> "numFound":8,
> "maxScore":1.0,
> "time":898}},
> {code}
> And my second choice would be:
> {code}
> "shards.info":{
>
> "207.237.114.232:8984/solr/collection1/|207.237.114.232:8986/solr/collection1/":{
> "shardName": "shard2",
> "numFound":2,
> "maxScore":1.0,
> "time":224},
>
> "207.237.114.232:8983/solr/collection1/|207.237.114.232:8985/solr/collection1/":{
> "shardName": "shard1",
> "numFound":8,
> "maxScore":1.0,
> "time":898}},
> {code}
> (We don't have shard "name", but I presume that at some point we will. For
> now, it would just be the shard ID.)
> I suppose the second choice might be better for non-cloud traditional
> distributed Solr - where there is no shard ID/name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
