unrelated to your question, but we should give a better error...
https://issues.apache.org/jira/browse/SOLR-435
On Oct 20, 2008, at 8:01 PM, Grant Ingersoll wrote:
For completeness, here's the NPE:
SEVERE: java.lang.NullPointerException
at org.apache.solr.common.util.StrUtils.splitSmart(StrUtils.java:37)
at
org
.apache.solr.search.OldLuceneQParser.parse(LuceneQParserPlugin.java:
104)
at org.apache.solr.search.QParser.getQuery(QParser.java:88)
at
org
.apache
.solr.handler.component.QueryComponent.prepare(QueryComponent.java:82)
at
org
.apache
.solr
.handler
.component.SearchHandler.handleRequestBody(SearchHandler.java:149)
at
org
.apache
.solr
.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at
org
.apache
.solr
.handler
.clustering
.ClusteringComponentTest.testComponent(ClusteringComponentTest.java:
70)
Don't worry about the ClusteringComponentTest yet, I haven't posted
that code yet.
On Oct 20, 2008, at 7:56 PM, Grant Ingersoll wrote:
I've run into this a couple of times now and I feel like it
warrants a discussion
For both the SpellCheckComponent (SCC) and now for the new
ClusteringComponent (SOLR-769) I think there are cases where the
QueryComponent (QC) is not required. In the SpellCheckComponent
case it is when building the spelling index. In the
ClusteringComponent, it is possible to ask for document clusters
without running any query (it also will be possible to get clusters
_with_ a query as well, and it also is distinguished from the
handling of search results clustering, too). Thus, it seems really
weird to have to pass in a dummy query, yet that is what one has to
do in order to avoid getting an NPE in the QC.
Now, I suppose these pieces could be modeled as something else or
it's possible to split the two functionalities into separate things
(1 ReqHandler, 1 SearchComp). In fact, the said functionality is
not really "search" functionality, or SearchComponent
functionality, yet much of the rest of the functionality in the
code in question is "search" functionality and logically belongs as
a SearchComponent. In the case of the SCC build, it's akin to an
indexing operation. In the clustering case, it's a query, albeit a
non-traditional one. In some sense, this kind of document
clustering is like non-query based faceting which leads to more
navigation/browsing instead of searching.
The quick fix is to just put in null checks into the QC or pass in
a dummy query with rows=0, but I'm not sure if there isn't a
slightly bigger picture here that needs adjusting in terms of
SearchComponents. Namely, must the QC always be on? And, should
we think a little more about components that don't require a query
in order to function and how they play in the scheme of things?
Thoughts? Recommendations?
-Grant
