You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2013/08/19 22:17:48 UTC
[jira] [Updated] (SOLR-4304) Coupling between
SpellCheckComponent(s) and QueryConverter(s) is a mess and makes no sense
[ https://issues.apache.org/jira/browse/SOLR-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hoss Man updated SOLR-4304:
---------------------------
Description:
The initial report here (from [~jkrupan]) was that if you configured multiple {{<queryConvertor>}} instances you would get an NPE because the SpellCheckComponent's inform() method assumes there will be at most 1.
Looking into this more deeply, it's actually just a surface symptom of a much more significant problem...
* QueryConverters can be configured as "first order" type plugins in solrconfig.xml using the {{<queryConverter>}} syntax, with the ability to have multiple instances each with their own names
* QueryConvertors don't seem to actually be instantiated/initialized unless there is a SpellCheckComponent -- but if there are more then one SpellCheckComponent instances, then the QueryConverters will all be initialzed again and again.
* SpellCheckComponent expects there to be 0 or 1 QueryConvertors, throwing an NPE if multiple QueryConvertors are configured -- there is no spellcheck request param to request a QueryConvertor by name.
* even if we tried to add a request param to pick a QueryConvertor by name -- the SpellCheckComponent has a "queryAnalyzerFieldType" init param that is used to get an Analyzer which is passed to QueryConverter.setAnalyzer() on init -- making it impossible to use multiple QueryConverter's with a single SpellCheckComponent, or a single (custom) QueryConvertor with multiple SpellCheckComponents with differnet queryAnalyzerFieldType init params
** NOTE: if 0 QueryConverters are configured then *each* SpellCheckComponent creates it's own private instance of "SpellingQueryConverter" -- so there is no serious problem in this (default) situation with the SpellCheckComponent's being configured to use different queryAnalyzerFieldTypes
----
Initial steps reported to reproduce the NPE...
1. Add to 4.0 example solrconfig.xml:
{code}
<queryConverter name="myQueryConverter-1" class="solr.SpellingQueryConverter"/>
<queryConverter name="myQueryConverter-2" class="solr.SuggestQueryConverter"/>
{code}
2. Perform a spellcheck request:
{{curl "http://localhost:8983/solr/spell?q=test&indent=true"}}
was:
The Solr SpellCheckComponent uses only a single QueryConverter, but fails with an NPE if more than one QueryConverter class is registered in solrconfig.xml.
Repro:
1. Add to 4.0 example solrconfig.xml:
<queryConverter name="myQueryConverter-1" class="solr.SpellingQueryConverter"/>
<queryConverter name="myQueryConverter-2" class="solr.SuggestQueryConverter"/>
2. Perform a spellcheck request:
curl "http://localhost:8983/solr/spell?q=test&indent=true"
3. Examine the NPE:
<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
<int name="status">500</int>
<int name="QTime">4</int>
</lst>
<result name="response" numFound="0" start="0">
</result>
<lst name="error">
<str name="trace">java.lang.NullPointerException
at org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:136)
at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:206)
at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.RequestHandlers$LazyRequestHandlerWrapper.handleRequest(RequestHandlers.java:240)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1699)
at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:455)
at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:276)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)
at org.eclipse.jetty.server.Server.handle(Server.java:351)
at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)
at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47)
at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890)
at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)
at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66)
at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534)
at java.lang.Thread.run(Unknown Source)
</str>
<int name="code">500</int>
</lst>
</response>
Suggested resolution: Use the first QueryConverter, but give a warning that indicates the class name of the one being used. Alternatively, throw a nasty but informative exception indicating the true nature of the problem.
Summary: Coupling between SpellCheckComponent(s) and QueryConverter(s) is a mess and makes no sense (was: NPE in Solr SpellCheckComponent if more than one QueryConverter)
I've updated the summary & description to include more info about hte broader problem of having multiple QueryConverters *or* multiple SpellCheckComponents.
For now, as part of the work i'm doing in SOLR-5108 i'll lock down the config parsing to support at most 1 instance of {{<queryConverter>}} (since that's all that's ever worked anyway because of this NPE)
Moving forward, we should figure out some way to resolve this cluster-fuck of interconnectedness.
Off the top of my head: perhaps the cleanest thing to do would be:
* continue to have {{<queryConverter>}} be top level declarations
* continue to have _each_ SpellCheckComponent init a copy of each configured {{<queryConverter>}}
* Change SpellCheckComponent to keep track of all the QueryConverters it initializes -- and call setAnalyzer on all of them
* Change SpellCheckComponent to let you pick a converter by name at request time.
...ie: top level configuration, component level objects.
> Coupling between SpellCheckComponent(s) and QueryConverter(s) is a mess and makes no sense
> ------------------------------------------------------------------------------------------
>
> Key: SOLR-4304
> URL: https://issues.apache.org/jira/browse/SOLR-4304
> Project: Solr
> Issue Type: Bug
> Components: spellchecker
> Affects Versions: 4.0
> Reporter: Jack Krupansky
>
> The initial report here (from [~jkrupan]) was that if you configured multiple {{<queryConvertor>}} instances you would get an NPE because the SpellCheckComponent's inform() method assumes there will be at most 1.
> Looking into this more deeply, it's actually just a surface symptom of a much more significant problem...
> * QueryConverters can be configured as "first order" type plugins in solrconfig.xml using the {{<queryConverter>}} syntax, with the ability to have multiple instances each with their own names
> * QueryConvertors don't seem to actually be instantiated/initialized unless there is a SpellCheckComponent -- but if there are more then one SpellCheckComponent instances, then the QueryConverters will all be initialzed again and again.
> * SpellCheckComponent expects there to be 0 or 1 QueryConvertors, throwing an NPE if multiple QueryConvertors are configured -- there is no spellcheck request param to request a QueryConvertor by name.
> * even if we tried to add a request param to pick a QueryConvertor by name -- the SpellCheckComponent has a "queryAnalyzerFieldType" init param that is used to get an Analyzer which is passed to QueryConverter.setAnalyzer() on init -- making it impossible to use multiple QueryConverter's with a single SpellCheckComponent, or a single (custom) QueryConvertor with multiple SpellCheckComponents with differnet queryAnalyzerFieldType init params
> ** NOTE: if 0 QueryConverters are configured then *each* SpellCheckComponent creates it's own private instance of "SpellingQueryConverter" -- so there is no serious problem in this (default) situation with the SpellCheckComponent's being configured to use different queryAnalyzerFieldTypes
> ----
> Initial steps reported to reproduce the NPE...
> 1. Add to 4.0 example solrconfig.xml:
> {code}
> <queryConverter name="myQueryConverter-1" class="solr.SpellingQueryConverter"/>
> <queryConverter name="myQueryConverter-2" class="solr.SuggestQueryConverter"/>
> {code}
> 2. Perform a spellcheck request:
> {{curl "http://localhost:8983/solr/spell?q=test&indent=true"}}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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