[ https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16674556#comment-16674556 ]
Gus Heck commented on SOLR-12938: --------------------------------- [~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