[ 
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tomás Fernández Löbbe reassigned SOLR-12938:
--------------------------------------------

    Assignee: Tomás Fernández Löbbe  (was: Gus Heck)

> 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: Tomás Fernández Löbbe
>            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

Reply via email to