[jira] [Commented] (SOLR-12938) ClusterStatus should not spew an exception trace if it gets an alias name
[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16679136#comment-16679136
]
ASF subversion and git services commented on SOLR-12938:
Commit 53482e510c773fabd80fc0a5a0efa1f137f89def in lucene-solr's branch
refs/heads/master from [~gh_at]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=53482e5 ]
SOLR-12938 - fix test case for handling of bogus collection names
that was failing when HttpClusterStateProvider is used instead of
ZkClusterStateProvider
> 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
[jira] [Commented] (SOLR-12938) ClusterStatus should not spew an exception trace if it gets an alias name
[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16678919#comment-16678919
]
ASF subversion and git services commented on SOLR-12938:
Commit 3dc79917148e8753d4f5544b5604708143f92499 in lucene-solr's branch
refs/heads/branch_7x from [~gh_at]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3dc7991 ]
SOLR-12938 - fix test case for handling of bogus collection names
that was failing when HttpClusterStateProvider is used instead of
ZkClusterStateProvider
> 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
[jira] [Commented] (SOLR-12938) ClusterStatus should not spew an exception trace if it gets an alias name
[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677663#comment-16677663
]
Gus Heck commented on SOLR-12938:
-
This is fixed on my machine, the individual test class successfully beasted 50
rounds using 5 vms at a time with Mark Miller's beasting
[gist|https://bit.ly/2SRS8kL]
(but not applying his hardening PR) and I got zero failures. Without the fix I
get frequent failures under the same conditions.
However, I'm seeing some failures (10-20% of beast rounds) in a wide variety of
methods in that test class if I crank up the number of vm's such that all my
cores are in use, so I think this test class (CloudSolrClientTest) is generally
flakey under heavy load. The number of 404 error messages with text/html
unexpected almost tripples from 60ish to 160ish if I run with 25 vms instead of
5.
I'm running the full test suites now and will again in the morning and will
likely commit the fix tomorrow assuming all goes well.
> 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
[jira] [Commented] (SOLR-12938) ClusterStatus should not spew an exception trace if it gets an alias name
[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677372#comment-16677372
]
Gus Heck commented on SOLR-12938:
-
Ah this test seems to pass 5 out of 15 tries for me... unlucky me. I think I'm
going to use this as an excuse to get better with beasting...
> 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
[jira] [Commented] (SOLR-12938) ClusterStatus should not spew an exception trace if it gets an alias name
[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[jira] [Commented] (SOLR-12938) ClusterStatus should not spew an exception trace if it gets an alias name
[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677202#comment-16677202
]
Gus Heck commented on SOLR-12938:
-
eek. I'll look into it tonight.
> 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
[jira] [Commented] (SOLR-12938) ClusterStatus should not spew an exception trace if it gets an alias name
[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677194#comment-16677194
]
David Smiley commented on SOLR-12938:
-
Take heart Gus; I broke half the tests on my first commit :)
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.
> 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
[jira] [Commented] (SOLR-12938) ClusterStatus should not spew an exception trace if it gets an alias name
[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677072#comment-16677072
]
Hoss Man commented on SOLR-12938:
-
FWIW: searching jenkins emails for {{"FAILED:
org.apache.solr.client.solrj.impl.CloudSolrClientTest.testCollectionDoesntExist"}}
matches 26 messages -- 25 of them in the past 2 days (the lone holdout being
over a year old) ... hence i started git bisecting with
7d6d77d06753bd131aeb37531b70c59193917683 and identified
5ad78734384104d7e26d51917d04936b849a692d as the root cause.
> 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
[jira] [Commented] (SOLR-12938) ClusterStatus should not spew an exception trace if it gets an alias name
[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677061#comment-16677061
]
Hoss Man commented on SOLR-12938:
-
Gus: digging into recent jenkins failures of CloudSolrClientTest shows that
this change seems to have caused a *lot* of reproduible failures.
{noformat}
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}
...fails reliably on HEAD of branch_7x
(7d6d77d06753bd131aeb37531b70c59193917683) and against the cmmit from this
issue (5ad78734384104d7e26d51917d04936b849a692d) but does not fail against the
previous commit on branch_7x
> 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
[jira] [Commented] (SOLR-12938) ClusterStatus should not spew an exception trace if it gets an alias name
[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16674970#comment-16674970
]
ASF subversion and git services commented on SOLR-12938:
Commit 45b772f4a995c618b48ff05c6129c5683df92f88 in lucene-solr's branch
refs/heads/jira/http2 from [~gh_at]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=45b772f ]
SOLR-12938 - Cluster status now returns results for aliases instead of
throwing an exception
> 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
[jira] [Commented] (SOLR-12938) ClusterStatus should not spew an exception trace if it gets an alias name
[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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
[jira] [Commented] (SOLR-12938) ClusterStatus should not spew an exception trace if it gets an alias name
[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16674463#comment-16674463
]
Tomás Fernández Löbbe commented on SOLR-12938:
--
Is this really what we should do here? I'm a bit out of context, so maybe this
is in fact the right thing, however, all other collection operations do not
(and should not IMO) operate on aliases, why would the CLUSTERSTATUS be
different?
> 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
[jira] [Commented] (SOLR-12938) ClusterStatus should not spew an exception trace if it gets an alias name
[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16674458#comment-16674458
]
ASF subversion and git services commented on SOLR-12938:
Commit 5ad78734384104d7e26d51917d04936b849a692d in lucene-solr's branch
refs/heads/branch_7x from [~gh_at]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=5ad7873 ]
SOLR-12938 - Cluster status now returns results for aliases instead of
throwing an exception
> 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
> 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
[jira] [Commented] (SOLR-12938) ClusterStatus should not spew an exception trace if it gets an alias name
[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16674440#comment-16674440
]
ASF subversion and git services commented on SOLR-12938:
Commit 45b772f4a995c618b48ff05c6129c5683df92f88 in lucene-solr's branch
refs/heads/master from [~gh_at]
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=45b772f ]
SOLR-12938 - Cluster status now returns results for aliases instead of
throwing an exception
> 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
> 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
[jira] [Commented] (SOLR-12938) ClusterStatus should not spew an exception trace if it gets an alias name
[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16672760#comment-16672760
]
Andrzej Bialecki commented on SOLR-12938:
--
+1, looks good.
> 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
> 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
[jira] [Commented] (SOLR-12938) ClusterStatus should not spew an exception trace if it gets an alias name
[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16672437#comment-16672437
]
Gus Heck commented on SOLR-12938:
-
Updated patch, with ref guide update & CHANGES.txt. If there's no concerns
raised I'll commit it to 7x and master this weekend.
> 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
> 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
[jira] [Commented] (SOLR-12938) ClusterStatus should not spew an exception trace if it gets an alias name
[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16672070#comment-16672070
]
David Smiley commented on SOLR-12938:
-
Definitely an irritant that I'm looking forward to being remedied. Thanks for
filing this Gus.
> 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
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-12938) ClusterStatus should not spew an exception trace if it gets an alias name
[
https://issues.apache.org/jira/browse/SOLR-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
