[jira] [Updated] (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:all-tabpanel
]
Hoss Man updated SOLR-12938:
Priority: Blocker (was: Minor)
setting as blocker to ensure that we either roll back and get to the bottom of
test failures before releasing in 7.6
> 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] [Updated] (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:all-tabpanel
]
Gus Heck updated SOLR-12938:
Fix Version/s: master (8.0)
7.6
> 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] [Updated] (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:all-tabpanel
]
Gus Heck updated SOLR-12938:
Attachment: SOLR-12938.patch
> 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] [Updated] (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:all-tabpanel
]
Gus Heck updated SOLR-12938:
Attachment: SOLR-12938.patch
> 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
>
>
> 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] [Updated] (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:all-tabpanel
]
Gus Heck updated SOLR-12938:
Attachment: SOLR-12938.patch
> 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
[jira] [Updated] (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:all-tabpanel
]
Gus Heck updated SOLR-12938:
Description:
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.
was:
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-12948 . 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.
> 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
>
> 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
[jira] [Updated] (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:all-tabpanel
]
Gus Heck updated SOLR-12938:
Description:
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-12948 . 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.
was:
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-12948. 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.
> 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
>
> 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-12948 . 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
