You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Oleg Alexeyev (JIRA)" <ji...@apache.org> on 2014/05/01 16:36:17 UTC
[jira] [Created] (SOLR-6038) Errors on core start are not properly
propagated to Solr clients
Oleg Alexeyev created SOLR-6038:
-----------------------------------
Summary: Errors on core start are not properly propagated to Solr clients
Key: SOLR-6038
URL: https://issues.apache.org/jira/browse/SOLR-6038
Project: Solr
Issue Type: Bug
Affects Versions: 4.8
Environment: Standalone Solr - solr.war deployed to Tomcat 7.
Reporter: Oleg Alexeyev
Priority: Minor
If a core cannot start (in our case index was manually corrupted), and client tries to query, Solr throws org.apache.solr.common.SolrException: Unable to create core: <core-name>, which is not handled by Solr itself and therefore handled by Tomcat - it renders an HTML page with stack trace as the response.
SolrJ, in turn, first checks for the content type (HttpSolrServer.executeMethod() - switch (httpStatus):default is skipped because processor != null). And since response is not application/octet-stream as expected for javabin, but text/html instead, throws org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Expected mime type application/octet-stream but got text/html. <html><head><title>Apache Tomcat/7.0.50 - Error report... - printing the whole HTML page into the message. As result, our logs contain unreadable huge exceptions with HTML, Solr server side stack traces and unclear reason that content type doesn't match. While it would perfectly OK to simply print "internal server error" meaning we should check Solr logs.
Currently we're working around that as follows:
- add error page reference to Tomcat's conf/web.xml:
<error-page>
<exception>java.lang.Throwable</exception>
<location>/errors/throwable-javabin.jsp</location>
</error-page>
- add throwable-javabin.jsp to webapps/solr/errors/:
<%@ page contentType="application/octet-stream" %><%
new org.apache.solr.common.util.JavaBinCodec().marshal(new org.apache.solr.common.util.NamedList(), response.getOutputStream());
%>
This way, when an exception happens, Solr responds with an empty valid javabin named list. And SolrJ passes content type check and response parsing. Then it properly fails on further http status check (HttpSolrServer.executeMethod() - httpStatus != HttpStatus.SC_OK) and we get a nice message like org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Internal Server Error
request: http://localhost:8983/solr/core/select?q=...
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org