[jira] [Commented] (SOLR-8016) CloudSolrClient has extremely verbose error logging

["Greg Pendlebury (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 [~markrmiller@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org