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
