[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16674556#comment-16674556
]
Gus Heck edited comment on SOLR-12938 at 11/5/18 12:28 AM:
-----------------------------------------------------------
[~tomasflobbe] The original impetus for this was the spurious exception
messages that are a result of resolving aliases (this appears to have been
introduced by the change to CloudSolrClient#resolveAliases (#getCollectionNames
at that time) as part of
[https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5650939]
That change came about as the result of a long discussion of concurrency/leader
up/down problems see SOLR-9784 and SOLR-9512
Because the heuristic used for detecting aliases was a CLUSTERSTATUS call that
failed (causing a stack trace), there are 2 ways to fix this:
# Change the hueristic - one could request a full clusters status rather than
status on just the collection and check more directly for the presence of the
collection in the keyset of the map of collections and then in the key set of
the map of aliases. This seems like it could be quite heavy on large clusters,
which I'm guessing is why it wasn't done this way ([~noble.paul] can probably
tell us if I guessed correctly there). I haven't thought of another method that
doesn't involve much more significant enhancements to CLUSTERSTATUS (such as
maybe a "shallow" option) and more work/complexity
# Don't throw an exception when asked about an alias - However if we aren't
going to throw an exception and return an error, we need something sensible to
return. The simplest and most logical answer to that was to return the details
for the collections in the alias. This struck me as simpler and providing
additional potentially useful functionality. This seems like it may become
particularly useful with TimeRoutedAliases that are very likely to be treated
like a single collection as much as possible. There is a tiny bit of possible
wierdness I just thought of but haven't tested where we probably still return
the list of all aliases, not just the alias asked about in the aliases section.
If that's the case I may amend this to cull the unrelated info out of the
response.
As for Collection operations not working with Aliases, conceptually
*CLUSTER*STATUS is not really collection operation to my mind anyway, it's a
cluster level operation that can return info about the cluster or subsections
of it that happens to hang out in the collections API since there's no Cluster
API (v1).
was (Author: gus_heck):
[~tomasflobbe] The original impetus for this was the spurious exception
messages that are a result of resolving aliases (this appears to have been
introduced by the change to CloudSolrClient#resolveAliases (#getCollectionNames
at that time) as part of
[https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5650939]
That change came about as the result of a long discussion of concurrency/leader
up/down problems see SOLR-9784 and SOLR-9512
Because the heuristic used for detecting aliases was a CLUSTERSTATUS call that
failed (causing a stack trace), there are 2 ways to fix this:
# Change the hueristic - one could request a full clusters status rather than
status on just the collection and check more directly for the presence of the
collection in the keyset of the map of collections and then in the key set of
the map of aliases. This seems like it could be quite heavy on large clusters,
which I'm guessing is why it wasn't done this way ([~noble.paul] can probably
tell us if I guessed correctly there). I haven't thought of another method that
doesn't involve much more significant enhancements to CLUSTERSTATUS (such as
maybe a "shallow" option) and more work/complexity
# Don't throw an exception when asked about an alias - However if we aren't
going to throw an exception and return an error, we need something sensible to
return. The simplest and most logical answer to that was to return the details
for the collections in the alias. This struck me as simpler and providing
additional potentially useful functionality. This seems like it may become
particularly useful with TimeRoutedAliases that are very likely to be treated
like a single collection as much as possible. There is a tiny bit of possible
wierdness I just thought of but haven't tested where we probably still return
the list of all aliases, not just the alias asked about in the aliases section.
If that's the case I may amend this to cull the unrelated info out of the
response.
As for Collection operations not working with Aliases, conceptually
*CLUSTER*STATUS is not really collection operation to my mind anyway, it's a
cluster level operation that can return info about the cluster or subsections
of it that happens to hang out in the collections API since there's no Cluster
API.
> 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
