lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Alexeyev (JIRA)" <>
Subject [jira] [Created] (SOLR-6038) Errors on core start are not properly propagated to Solr clients
Date Thu, 01 May 2014 14:36:17 GMT
Oleg Alexeyev created SOLR-6038:

             Summary: Errors on core start are not properly propagated to Solr clients
                 Key: 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:
- 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(),

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

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

View raw message