lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Pendlebury (JIRA)" <>
Subject [jira] [Commented] (SOLR-8016) CloudSolrClient has extremely verbose error logging
Date Wed, 19 Oct 2016 01:06:58 GMT


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 []'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:
>             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
> 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 ( 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message