[jira] [Commented] (SOLR-8016) CloudSolrClient has extremely verbose error logging
[
https://issues.apache.org/jira/browse/SOLR-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15587251#comment-15587251
]
Greg Pendlebury commented on SOLR-8016:
---
Not that I am aware of. I can see the problem still in our newest server
(5.5.3). I like [~markrmil...@gmail.com]'s suggestion of lowering the log level
to info. It is simple and we can filter it out via logging config. The deeper
issues of whether the retry should even be attempted sound interesting to me,
but I'd be happy to just not see the log entries.
> CloudSolrClient has extremely verbose error logging
> ---
>
> Key: SOLR-8016
> URL: https://issues.apache.org/jira/browse/SOLR-8016
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 5.2.1, 6.0
>Reporter: Greg Pendlebury
>Priority: Minor
> Labels: easyfix
>
> CloudSolrClient has this error logging line which is fairly annoying:
> {code}
> log.error("Request to collection {} failed due to ("+errorCode+
> ") {}, retry? "+retryCount, collection, rootCause.toString());
> {code}
> Given that this is a client library and then gets embedded into other
> applications this line is very problematic to handle gracefully. In today's
> example I was looking at, every failed search was logging over 100 lines,
> including the full HTML response from the responding node in the cluster.
> The resulting SolrServerException that comes out to our application is
> handled appropriately but we can't stop this class complaining in logs
> without suppressing the entire ERROR channel, which we don't want to do. This
> is the only direct line writing to the log I could find in the client, so we
> _could_ suppress errors, but that just feels dirty, and fragile for the
> future.
> From looking at the code I am fairly certain it is not as simple as throwing
> an exception instead of logging... it is right in the middle of the method. I
> suspect the simplest answer is adding a marker
> (http://www.slf4j.org/api/org/slf4j/Marker.html) to the logging call.
> Then solrj users can choose what to do with these log entries. I don't know
> if there is a broader strategy for handling this that I am ignorant of;
> apologies if that is the case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8016) CloudSolrClient has extremely verbose error logging
[
https://issues.apache.org/jira/browse/SOLR-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15529128#comment-15529128
]
Jan Høydahl commented on SOLR-8016:
---
Any conclusion on this?
> CloudSolrClient has extremely verbose error logging
> ---
>
> Key: SOLR-8016
> URL: https://issues.apache.org/jira/browse/SOLR-8016
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 5.2.1, 6.0
>Reporter: Greg Pendlebury
>Priority: Minor
> Labels: easyfix
>
> CloudSolrClient has this error logging line which is fairly annoying:
> {code}
> log.error("Request to collection {} failed due to ("+errorCode+
> ") {}, retry? "+retryCount, collection, rootCause.toString());
> {code}
> Given that this is a client library and then gets embedded into other
> applications this line is very problematic to handle gracefully. In today's
> example I was looking at, every failed search was logging over 100 lines,
> including the full HTML response from the responding node in the cluster.
> The resulting SolrServerException that comes out to our application is
> handled appropriately but we can't stop this class complaining in logs
> without suppressing the entire ERROR channel, which we don't want to do. This
> is the only direct line writing to the log I could find in the client, so we
> _could_ suppress errors, but that just feels dirty, and fragile for the
> future.
> From looking at the code I am fairly certain it is not as simple as throwing
> an exception instead of logging... it is right in the middle of the method. I
> suspect the simplest answer is adding a marker
> (http://www.slf4j.org/api/org/slf4j/Marker.html) to the logging call.
> Then solrj users can choose what to do with these log entries. I don't know
> if there is a broader strategy for handling this that I am ignorant of;
> apologies if that is the case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8016) CloudSolrClient has extremely verbose error logging
[
https://issues.apache.org/jira/browse/SOLR-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14735752#comment-14735752
]
Greg Pendlebury commented on SOLR-8016:
---
Lowering the level to INFO would be good in our case, although when you say
that after all the retries it will eventually error would just delay the
event... unless the error is thrown instead of logged. The Solr nodes were in a
bad way and needed intervention from sysadmins because of locked index segments
from a graceless shutdown.
Under this scenario, the UI clients were logging enormous amounts of useless
content ('rootCause.toString()') and making finding other lines in the log very
difficult. Because the client also throws Exceptions we had already gracefully
handled the outage by degrading functionality.
With regards to Markers I have never used them personally, but before I
suggested them I looked at the fact that both log4j and logback support them
via slf4j. This covers both the solr default (log4j) and the binding we use in
production (logback) so I am selfishly happy with the possibility... and I
think it is the simplest change. I didn't want to propose a rethink of the
logging, or that method's flow, but I am happy if this prompts that as well.
> CloudSolrClient has extremely verbose error logging
> ---
>
> Key: SOLR-8016
> URL: https://issues.apache.org/jira/browse/SOLR-8016
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 5.2.1, Trunk
>Reporter: Greg Pendlebury
>Priority: Minor
> Labels: easyfix
>
> CloudSolrClient has this error logging line which is fairly annoying:
> {code}
> log.error("Request to collection {} failed due to ("+errorCode+
> ") {}, retry? "+retryCount, collection, rootCause.toString());
> {code}
> Given that this is a client library and then gets embedded into other
> applications this line is very problematic to handle gracefully. In today's
> example I was looking at, every failed search was logging over 100 lines,
> including the full HTML response from the responding node in the cluster.
> The resulting SolrServerException that comes out to our application is
> handled appropriately but we can't stop this class complaining in logs
> without suppressing the entire ERROR channel, which we don't want to do. This
> is the only direct line writing to the log I could find in the client, so we
> _could_ suppress errors, but that just feels dirty, and fragile for the
> future.
> From looking at the code I am fairly certain it is not as simple as throwing
> an exception instead of logging... it is right in the middle of the method. I
> suspect the simplest answer is adding a marker
> (http://www.slf4j.org/api/org/slf4j/Marker.html) to the logging call.
> Then solrj users can choose what to do with these log entries. I don't know
> if there is a broader strategy for handling this that I am ignorant of;
> apologies if that is the case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8016) CloudSolrClient has extremely verbose error logging
[
https://issues.apache.org/jira/browse/SOLR-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14735827#comment-14735827
]
Mark Miller commented on SOLR-8016:
---
Pretty sure CloudSolrClient should not be retrying on such errors. The load
balancing code is in another class - if anything, it might chose to retry
depending on the request type, but code in CloudSolrClient should probably not
be retrying in this case.
> CloudSolrClient has extremely verbose error logging
> ---
>
> Key: SOLR-8016
> URL: https://issues.apache.org/jira/browse/SOLR-8016
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 5.2.1, Trunk
>Reporter: Greg Pendlebury
>Priority: Minor
> Labels: easyfix
>
> CloudSolrClient has this error logging line which is fairly annoying:
> {code}
> log.error("Request to collection {} failed due to ("+errorCode+
> ") {}, retry? "+retryCount, collection, rootCause.toString());
> {code}
> Given that this is a client library and then gets embedded into other
> applications this line is very problematic to handle gracefully. In today's
> example I was looking at, every failed search was logging over 100 lines,
> including the full HTML response from the responding node in the cluster.
> The resulting SolrServerException that comes out to our application is
> handled appropriately but we can't stop this class complaining in logs
> without suppressing the entire ERROR channel, which we don't want to do. This
> is the only direct line writing to the log I could find in the client, so we
> _could_ suppress errors, but that just feels dirty, and fragile for the
> future.
> From looking at the code I am fairly certain it is not as simple as throwing
> an exception instead of logging... it is right in the middle of the method. I
> suspect the simplest answer is adding a marker
> (http://www.slf4j.org/api/org/slf4j/Marker.html) to the logging call.
> Then solrj users can choose what to do with these log entries. I don't know
> if there is a broader strategy for handling this that I am ignorant of;
> apologies if that is the case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8016) CloudSolrClient has extremely verbose error logging
[
https://issues.apache.org/jira/browse/SOLR-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14735798#comment-14735798
]
Mark Miller commented on SOLR-8016:
---
That sounds like a different issue - the CloudSolrClient really should not be
retrying like this on such an error?
> CloudSolrClient has extremely verbose error logging
> ---
>
> Key: SOLR-8016
> URL: https://issues.apache.org/jira/browse/SOLR-8016
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 5.2.1, Trunk
>Reporter: Greg Pendlebury
>Priority: Minor
> Labels: easyfix
>
> CloudSolrClient has this error logging line which is fairly annoying:
> {code}
> log.error("Request to collection {} failed due to ("+errorCode+
> ") {}, retry? "+retryCount, collection, rootCause.toString());
> {code}
> Given that this is a client library and then gets embedded into other
> applications this line is very problematic to handle gracefully. In today's
> example I was looking at, every failed search was logging over 100 lines,
> including the full HTML response from the responding node in the cluster.
> The resulting SolrServerException that comes out to our application is
> handled appropriately but we can't stop this class complaining in logs
> without suppressing the entire ERROR channel, which we don't want to do. This
> is the only direct line writing to the log I could find in the client, so we
> _could_ suppress errors, but that just feels dirty, and fragile for the
> future.
> From looking at the code I am fairly certain it is not as simple as throwing
> an exception instead of logging... it is right in the middle of the method. I
> suspect the simplest answer is adding a marker
> (http://www.slf4j.org/api/org/slf4j/Marker.html) to the logging call.
> Then solrj users can choose what to do with these log entries. I don't know
> if there is a broader strategy for handling this that I am ignorant of;
> apologies if that is the case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8016) CloudSolrClient has extremely verbose error logging
[
https://issues.apache.org/jira/browse/SOLR-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14735813#comment-14735813
]
Greg Pendlebury commented on SOLR-8016:
---
I haven't looked at the innards of the method enough to say for sure. I know in
our particular use case it is fruitless to keep trying. The nodes are online,
but cannot answer in the way expected:
{code}
ERROR o.a.s.c.s.i.CloudSolrClient - Request to collection trove failed due to
(500) org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:
Error from server at /solr/trove: Expected mime type
application/octet-stream but got text/html.
Error 500 {msg=SolrCore 'trove' is not available due to init failure:
Index locked for write for core
trove,trace=org.apache.solr.common.SolrException: SolrCore 'trove' is not
available due to init failure: Index locked for write for core trove
{code}
And then lots and lots more html output.
The Exception that bubbles up to our code is more than enough for us know where
to start looking:
{code}
ERROR a.g.n.n.c.r.SolrService - Solr search failed: No live SolrServers
available to handle this request:[]
{code}
> CloudSolrClient has extremely verbose error logging
> ---
>
> Key: SOLR-8016
> URL: https://issues.apache.org/jira/browse/SOLR-8016
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 5.2.1, Trunk
>Reporter: Greg Pendlebury
>Priority: Minor
> Labels: easyfix
>
> CloudSolrClient has this error logging line which is fairly annoying:
> {code}
> log.error("Request to collection {} failed due to ("+errorCode+
> ") {}, retry? "+retryCount, collection, rootCause.toString());
> {code}
> Given that this is a client library and then gets embedded into other
> applications this line is very problematic to handle gracefully. In today's
> example I was looking at, every failed search was logging over 100 lines,
> including the full HTML response from the responding node in the cluster.
> The resulting SolrServerException that comes out to our application is
> handled appropriately but we can't stop this class complaining in logs
> without suppressing the entire ERROR channel, which we don't want to do. This
> is the only direct line writing to the log I could find in the client, so we
> _could_ suppress errors, but that just feels dirty, and fragile for the
> future.
> From looking at the code I am fairly certain it is not as simple as throwing
> an exception instead of logging... it is right in the middle of the method. I
> suspect the simplest answer is adding a marker
> (http://www.slf4j.org/api/org/slf4j/Marker.html) to the logging call.
> Then solrj users can choose what to do with these log entries. I don't know
> if there is a broader strategy for handling this that I am ignorant of;
> apologies if that is the case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-8016) CloudSolrClient has extremely verbose error logging
[
https://issues.apache.org/jira/browse/SOLR-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14734935#comment-14734935
]
Mark Miller commented on SOLR-8016:
---
I think it is incorrect logging levels.
This method is expected to have to retry sometimes. When it does, it prints out
all kinds of errors and warnings. But this is an expected case.
Really, at most, the error and warn logging done in this area should be info
and then only perhaps log the error when the retries are done without success.
Markers don't seem very satisfying - do we know what implementations respect
them?
> CloudSolrClient has extremely verbose error logging
> ---
>
> Key: SOLR-8016
> URL: https://issues.apache.org/jira/browse/SOLR-8016
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 5.2.1, Trunk
>Reporter: Greg Pendlebury
>Priority: Minor
> Labels: easyfix
>
> CloudSolrClient has this error logging line which is fairly annoying:
> {code}
> log.error("Request to collection {} failed due to ("+errorCode+
> ") {}, retry? "+retryCount, collection, rootCause.toString());
> {code}
> Given that this is a client library and then gets embedded into other
> applications this line is very problematic to handle gracefully. In today's
> example I was looking at, every failed search was logging over 100 lines,
> including the full HTML response from the responding node in the cluster.
> The resulting SolrServerException that comes out to our application is
> handled appropriately but we can't stop this class complaining in logs
> without suppressing the entire ERROR channel, which we don't want to do. This
> is the only direct line writing to the log I could find in the client, so we
> _could_ suppress errors, but that just feels dirty, and fragile for the
> future.
> From looking at the code I am fairly certain it is not as simple as throwing
> an exception instead of logging... it is right in the middle of the method. I
> suspect the simplest answer is adding a marker
> (http://www.slf4j.org/api/org/slf4j/Marker.html) to the logging call.
> Then solrj users can choose what to do with these log entries. I don't know
> if there is a broader strategy for handling this that I am ignorant of;
> apologies if that is the case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
