[ 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