[
https://issues.apache.org/jira/browse/SOLR-14892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17201038#comment-17201038
]
David Smiley commented on SOLR-14892:
-------------------------------------
I chased this down to
org.apache.solr.handler.component.HttpShardHandler#createSliceShardsStr which
when given an empty list, returns an empty string. It should probably return
null. But using But null has ripple effects in many places which assume
non-null values and maybe were written without shards.tolerant in mind. Lets
say it remains an empty string. SearchHandler.handleRequestBody loops over
"sreq.actualShards" which can yield that empty string. I hoped simply
"continue"-ing this loop on this occurrence may help but it led to some other
mystery. The code involved in general here is awfully messy.
> shards.info with shards.tolerant can yield an empty key
> -------------------------------------------------------
>
> Key: SOLR-14892
> URL: https://issues.apache.org/jira/browse/SOLR-14892
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Components: search
> Reporter: David Smiley
> Priority: Minor
> Attachments: solr14892.png
>
>
> When using shards.tolerant=true and shards.info=true when a shard isn't
> available (and maybe other circumstances), the shards.info section of the
> response may have an empty-string key child with a value that is ambiguous as
> to which shard(s) couldn't be reached.
> This problem can be revealed by modifying
> org.apache.solr.cloud.TestDownShardTolerantSearch#searchingShouldFailWithoutTolerantSearchSetToTrue
> to add shards.info and then examine the response in a debugger.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
