Greg Pendlebury created SOLR-8016:
-------------------------------------
Summary: 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
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
