[
https://issues.apache.org/jira/browse/SOLR-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14735813#comment-14735813
]
Greg Pendlebury commented on SOLR-8016:
---------------------------------------
I haven't looked at the innards of the method enough to say for sure. I know in
our particular use case it is fruitless to keep trying. The nodes are online,
but cannot answer in the way expected:
{code}
ERROR o.a.s.c.s.i.CloudSolrClient - Request to collection trove failed due to
(500) org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:
Error from server at <snip>/solr/trove: Expected mime type
application/octet-stream but got text/html. <html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"/>
<title>Error 500 {msg=SolrCore 'trove' is not available due to init failure:
Index locked for write for core
trove,trace=org.apache.solr.common.SolrException: SolrCore 'trove' is not
available due to init failure: Index locked for write for core trove
{code}
And then lots and lots more html output.
The Exception that bubbles up to our code is more than enough for us know where
to start looking:
{code}
ERROR a.g.n.n.c.r.SolrService - Solr search failed: No live SolrServers
available to handle this request:[<snip>]
{code}
> 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
