[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16669485#comment-16669485
]
Gus Heck commented on SOLR-12938:
---------------------------------
Attaching patch that does the following:
a) If its an alias, grab full cluster status and filter out any collections not
in the alias, then continue as if it were full cluster status (i.e. null was
passed for collection)
b) If the value passed for collection is neither a collection nor an alias,
still throw the prior exception
c) Fix several spots in HttpClusterStateProvider that threw null pointer
exceptions or had similar problems after the change due to an implicit
assumption that there MUST be a collection available if CLUSTERSTATUS didn't
throw.
d) Introduce a local exception meant only to be thrown between the private
fetchClusterState methods and it's callers in the same class. This avoids the
parsing of the exception message. The intent is the exception never escape from
HttpClusterStateProvider, so it's a checked exception to make sure folks
remember to catch it.
This introduces a small but I'm hoping tolerable backwards incompatibility for
any code that relied on CLUSTERSTATUS to throw an exception for non-collection
and non-null input
[~ab], [~ichattopadhyaya] I see your names on much of HttpClusterStateProvider
so I would appreciate your review.
> 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
> Priority: Minor
> Attachments: 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: [email protected]
For additional commands, e-mail: [email protected]
