[
https://issues.apache.org/jira/browse/SOLR-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
