[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16677210#comment-16677210
]
Hoss Man commented on SOLR-12938:
---------------------------------
{quote}Hoss, can you please share the git bissect command line you ran to find
the problem? I'd like to save this so I can use it to aid in my own test
investigations.
{quote}
In general...
{noformat}
git bisect start KNOWN_GOOD KNOWN_BAD
git bisect run bash -c 'ant clean && cd PARENT_DIR_OF_TEST && REPRODUCE_LINE'
{noformat}
today specifically...
{noformat}
git bisect start 7d6d77d06753bd131aeb37531b70c59193917683
be8f611db1cbaf51622d8af5cd6efced4e338968
git bisect run bash -e 'ant clean && cd solr/solrj/ && ant test
-Dtestcase=CloudSolrClientTest -Dtests.seed=949992ED4AFA660A
-Dtests.multiplier=3 -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=kl
-Dtests.timezone=Europe/Oslo -Dtests.asserts=true
-Dtests.file.encoding=ISO-8859-1 -Dtests.method=testCollectionDoesntExist'
{noformat}
> 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: Blocker
> 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
