[ https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16677072#comment-16677072 ]
Hoss Man commented on SOLR-12938: --------------------------------- FWIW: searching jenkins emails for {{"FAILED: org.apache.solr.client.solrj.impl.CloudSolrClientTest.testCollectionDoesntExist"}} matches 26 messages -- 25 of them in the past 2 days (the lone holdout being over a year old) ... hence i started git bisecting with 7d6d77d06753bd131aeb37531b70c59193917683 and identified 5ad78734384104d7e26d51917d04936b849a692d as the root cause. > ClusterStatus should not spew an exception trace if it gets an alias name > ------------------------------------------------------------------------- > > Key: SOLR-12938 > URL: https://issues.apache.org/jira/browse/SOLR-12938 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) > Components: SolrCloud > Affects Versions: 7.5 > Reporter: Gus Heck > Assignee: Gus Heck > Priority: Minor > Fix For: 7.6, master (8.0) > > Attachments: SOLR-12938.patch, SOLR-12938.patch, SOLR-12938.patch > > > This has been a lingering irritant in debugging tests for time routed > aliases, previously mentioned in SOLR-11949 and can be seen frequently in > logs attached to SOLR-12928. Basically what happens is for one reason or > another cluster status is called on an alias rather than a collection and > this is treated identically to a collection name that doesn't exist. > This also has lead this bit of lovely exception message parsing in > HttpClusteStateProvider.java > {code:java} > } catch (SolrServerException | RemoteSolrException | IOException e) { > if (e.getMessage().contains(collection + " not found")) { > // Cluster state for the given collection was not found. > // Lets fetch/update our aliases: > getAliases(true); > return null; > } > log.warn("Attempt to fetch cluster state from " + > Utils.getBaseUrlForNodeName(nodeName, urlScheme) + " failed.", e); > } > {code} > Cluster status is already handled in the case of no collection name provided > by returning status on all collections. It would make more sense if this > command returned status on the component collections for the alias. > If that turns out to be difficult or cause too many problems this should at > least be downgraded to a non-stack trace warning message since this situation > does not represent a failure of the system. The error/stack should of course > be retained if neither a collection nor an alias exist. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org