You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mark Miller (JIRA)" <ji...@apache.org> on 2015/09/08 16:56:45 UTC

[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&focusedCommentId=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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org