Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Wed, 7 Dec 2011 16:44:40 +0000 (UTC)
From: "Grant Ingersoll (Updated) (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <1867014878.49831.1323276280142.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (SOLR-1730) Solr fails to start if
 QueryElevationComponent config is missing
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/SOLR-1730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Grant Ingersoll updated SOLR-1730:
----------------------------------

    Attachment: SOLR-1730.patch

A little bit of progress, namely in setting up some tests for this as well as fixing the logging of the main exception.

The BadComponentTest shows the error (as well as some issue with either the harness or core itself when it comes to bad components).  The QEC is just the symptom of what's wrong here, as all Components produce similar errors if the inform() fails.  The real question is, what should we do about it, since inform is called on reloads, not just at startup it gets a bit trickier with the fail early approach that one often wants.
                
> Solr fails to start if QueryElevationComponent config is missing
> ----------------------------------------------------------------
>
>                 Key: SOLR-1730
>                 URL: https://issues.apache.org/jira/browse/SOLR-1730
>             Project: Solr
>          Issue Type: Bug
>          Components: SearchComponents - other
>    Affects Versions: 1.4
>            Reporter: Mark Miller
>            Assignee: Grant Ingersoll
>              Labels: newdev
>             Fix For: 3.6, 4.0
>
>         Attachments: SOLR-1730.patch
>
>
> QueryElevationComponent tries to do preload some data if its config file does not exist:
> {code}
>         if (!exists){
>           // preload the first data
>           RefCounted<SolrIndexSearcher> searchHolder = null;
>           try {
>             searchHolder = core.getNewestSearcher(false);
>             IndexReader reader = searchHolder.get().getReader();
>             getElevationMap( reader, core );
>           } finally {
>             if (searchHolder != null) searchHolder.decref();
>           }
>         }
> {code}
> This does not work though, as asking for the newest searcher causes a request to be submitted to Solr before its ready to handle it:
> {code}
>      [java] SEVERE: java.lang.NullPointerException
>      [java] 	at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:173)
>      [java] 	at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
>      [java] 	at org.apache.solr.core.SolrCore.execute(SolrCore.java:1317)
>      [java] 	at org.apache.solr.core.QuerySenderListener.newSearcher(QuerySenderListener.java:52)
>      [java] 	at org.apache.solr.core.SolrCore$3.call(SolrCore.java:1147)
>      [java] 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
>      [java] 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> {code}
> The SearchHandler has not yet been core informed (as the QueryElevationComponent causes this as its getting core informed right before the SearchHandler) and so its components arraylist is still null.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org