Solr
  1. Solr
  2. SOLR-2509

spellcheck: StringIndexOutOfBoundsException: String index out of range: -1

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 3.1
    • Fix Version/s: 3.6, 4.0-ALPHA
    • Component/s: None
    • Labels:
      None
    • Environment:

      Debian Lenny
      JAVA Version "1.6.0_20"

      Description

      Hi,

      I'm a french user of SOLR and i've encountered a problem since i've installed SOLR 3.1.

      I've got an error with this query :
      cle_frbr:"LYSROUGE1149-73190"

      SEE COMMENTS BELOW

      I've tested to escape the minus char and the query worked :
      cle_frbr:"LYSROUGE1149(BACKSLASH)-73190"

      But, strange fact, if i change one letter in my query it works :
      cle_frbr:"LASROUGE1149-73190"

      I've tested the same query on SOLR 1.4 and it works !

      Can someone test the query on next line on a 3.1 SOLR version and tell me if he have the same problem ?
      yourfield:"LYSROUGE1149-73190"

      Where do the problem come from ?

      Thank you by advance for your help.

      Tom

      1. document.xml
        0.1 kB
        Steffen Elberg Godskesen
      2. schema.xml
        2 kB
        Steffen Elberg Godskesen
      3. solrconfig.xml
        1 kB
        Steffen Elberg Godskesen
      4. SOLR-2509.patch
        3 kB
        James Dyer
      5. SOLR-2509.patch
        5 kB
        Steffen Elberg Godskesen
      6. SOLR-2509.patch
        6 kB
        Erick Erickson

        Issue Links

          Activity

          Hide
          Erick Erickson added a comment -

          By the way, many thanks to Thomas and Steffen!

          Show
          Erick Erickson added a comment - By the way, many thanks to Thomas and Steffen!
          Hide
          Erick Erickson added a comment -

          Trunk r: 1211456
          3x r: 1211457

          Show
          Erick Erickson added a comment - Trunk r: 1211456 3x r: 1211457
          Hide
          Erick Erickson added a comment -

          Here's the updated patch. The only difference between this and the original is that I changed the failing test to expect pixmaa rather than pixma-a-b-c-d-e-f-g.

          If nobody objects, I'll commit this tomorrow (7-Dec) on both trunk and 3x.

          Show
          Erick Erickson added a comment - Here's the updated patch. The only difference between this and the original is that I changed the failing test to expect pixmaa rather than pixma-a-b-c-d-e-f-g. If nobody objects, I'll commit this tomorrow (7-Dec) on both trunk and 3x.
          Hide
          James Dyer added a comment -

          ahhhh. I see in r1022768 you combined "testCollate()" with "testCollate2()", where this test scenario was originally. Thanks for the clarification (and sorry!). So in fact this was added with SOLR-1630 (r987509), the comments therein are not very reassuring that it was a "correct" or "final" fix.

          Show
          James Dyer added a comment - ahhhh. I see in r1022768 you combined "testCollate()" with "testCollate2()", where this test scenario was originally. Thanks for the clarification (and sorry!). So in fact this was added with SOLR-1630 (r987509), the comments therein are not very reassuring that it was a "correct" or "final" fix.
          Hide
          Yonik Seeley added a comment -

          Indeed, this test scenario was added during a refactoring (r1022768) with no JIRA # or bug mentioned at all in the comments.

          My commit

          The commit comment said "tests: fix resource leaks and simplify", and hopefully that's all I did!

          Looking back wrt pixma, it looks like I replaced this:

          -  @Test
          -  public void testCollate2() throws Exception {
          -    SolrCore core = h.getCore();
          -    SearchComponent speller = core.getSearchComponent("spellcheck");
          -    assertTrue("speller is null and it shouldn't be", speller != null);
          -
          -    ModifiableSolrParams params = new ModifiableSolrParams();
          -    params.add(CommonParams.QT, "spellCheckCompRH");
          -    params.add(SpellCheckComponent.SPELLCHECK_BUILD, "true");
          -    params.add(CommonParams.Q, "pixma-a-b-c-d-e-f-g");
          -    params.add(SpellCheckComponent.COMPONENT_NAME, "true");
          -    params.add(SpellCheckComponent.SPELLCHECK_COLLATE, "true");
          -
          -    SolrRequestHandler handler = core.getRequestHandler("spellCheckCompRH");
          -    SolrQueryResponse rsp = new SolrQueryResponse();
          -    rsp.add("responseHeader", new SimpleOrderedMap());
          -    handler.handleRequest(new LocalSolrQueryRequest(core, params), rsp);
          -    NamedList values = rsp.getValues();
          -    NamedList spellCheck = (NamedList) values.get("spellcheck");
          -    NamedList suggestions = (NamedList) spellCheck.get("suggestions");
          -    String collation = (String) suggestions.get("collation");
          -    assertEquals("pixmaa", collation);
          -  }
          

          With this:

          +    assertJQ(req("json.nl","map", "qt",rh, SpellCheckComponent.COMPONENT_NAME, "true", "q","pixma-a-b-c-d-e-f-g", SpellCheckComponent.SPELLCHECK_COLLATE, "true")
          +       ,"/spellcheck/suggestions/collation=='pixmaa'"
          +    );
          
          Show
          Yonik Seeley added a comment - Indeed, this test scenario was added during a refactoring (r1022768) with no JIRA # or bug mentioned at all in the comments. My commit The commit comment said "tests: fix resource leaks and simplify", and hopefully that's all I did! Looking back wrt pixma, it looks like I replaced this: - @Test - public void testCollate2() throws Exception { - SolrCore core = h.getCore(); - SearchComponent speller = core.getSearchComponent( "spellcheck" ); - assertTrue( "speller is null and it shouldn't be" , speller != null ); - - ModifiableSolrParams params = new ModifiableSolrParams(); - params.add(CommonParams.QT, "spellCheckCompRH" ); - params.add(SpellCheckComponent.SPELLCHECK_BUILD, " true " ); - params.add(CommonParams.Q, "pixma-a-b-c-d-e-f-g" ); - params.add(SpellCheckComponent.COMPONENT_NAME, " true " ); - params.add(SpellCheckComponent.SPELLCHECK_COLLATE, " true " ); - - SolrRequestHandler handler = core.getRequestHandler( "spellCheckCompRH" ); - SolrQueryResponse rsp = new SolrQueryResponse(); - rsp.add( "responseHeader" , new SimpleOrderedMap()); - handler.handleRequest( new LocalSolrQueryRequest(core, params), rsp); - NamedList values = rsp.getValues(); - NamedList spellCheck = (NamedList) values.get( "spellcheck" ); - NamedList suggestions = (NamedList) spellCheck.get( "suggestions" ); - String collation = ( String ) suggestions.get( "collation" ); - assertEquals( "pixmaa" , collation); - } With this: + assertJQ(req( "json.nl" , "map" , "qt" ,rh, SpellCheckComponent.COMPONENT_NAME, " true " , "q" , "pixma-a-b-c-d-e-f-g" , SpellCheckComponent.SPELLCHECK_COLLATE, " true " ) + , "/spellcheck/suggestions/collation=='pixmaa'" + );
          Hide
          James Dyer added a comment -

          Steffen's changes are most certainly correct. The index contains "pixmaa" and we are querying on "pixma-a-b-c-d-e-f-g". The spelling index is using analyzer "lowerpunctfilt" (solrconfig-spellcheckcomponent.xml, line 44) which includes WordDelimiterFilter and "generateWordParts=1". So we would expect this query to tokenize down to "pixma" "a" "b" "c" "d" "e" "f" "g". As the Collate feature is only supposed to replace the misspelled token with the new one, I wonder why this test scenario would expect all 8 tokens to be replaced by 1 token .

          Indeed, this test scenario was added during a refactoring (r1022768) with no JIRA # or bug mentioned at all in the comments. So we can't know for sure why it was added. I'm thinking this is invalid. I would expect the correct collation to be "pixma-a-b-c-d-e-f-g".

          Just for grins, I put a "println" in SpellingQueryConverter to show the start & end offsets for each token before and after the patch. In both cases, we get the same token texts, but prior to the patch the offset values are clearly wrong.

          --before:
          TOKEN: pixma so=0 eo=19
          TOKEN: a so=0 eo=19
          TOKEN: b so=0 eo=19
          TOKEN: c so=0 eo=19
          TOKEN: d so=0 eo=19
          TOKEN: e so=0 eo=19
          TOKEN: f so=0 eo=19
          TOKEN: g so=0 eo=19
          TOKEN: pixmaabcdefg so=0 eo=19

          --after:
          TOKEN: pixma so=0 eo=5
          TOKEN: a so=6 eo=7
          TOKEN: b so=8 eo=9
          TOKEN: c so=10 eo=11
          TOKEN: d so=12 eo=13
          TOKEN: e so=14 eo=15
          TOKEN: f so=16 eo=17
          TOKEN: g so=18 eo=19
          TOKEN: pixmaabcdefg so=0 eo=19

          Show
          James Dyer added a comment - Steffen's changes are most certainly correct. The index contains "pixmaa" and we are querying on "pixma-a-b-c-d-e-f-g". The spelling index is using analyzer "lowerpunctfilt" (solrconfig-spellcheckcomponent.xml, line 44) which includes WordDelimiterFilter and "generateWordParts=1". So we would expect this query to tokenize down to "pixma" "a" "b" "c" "d" "e" "f" "g". As the Collate feature is only supposed to replace the misspelled token with the new one, I wonder why this test scenario would expect all 8 tokens to be replaced by 1 token . Indeed, this test scenario was added during a refactoring (r1022768) with no JIRA # or bug mentioned at all in the comments. So we can't know for sure why it was added. I'm thinking this is invalid. I would expect the correct collation to be "pixma-a-b-c-d-e-f-g". Just for grins, I put a "println" in SpellingQueryConverter to show the start & end offsets for each token before and after the patch. In both cases, we get the same token texts, but prior to the patch the offset values are clearly wrong. --before: TOKEN: pixma so=0 eo=19 TOKEN: a so=0 eo=19 TOKEN: b so=0 eo=19 TOKEN: c so=0 eo=19 TOKEN: d so=0 eo=19 TOKEN: e so=0 eo=19 TOKEN: f so=0 eo=19 TOKEN: g so=0 eo=19 TOKEN: pixmaabcdefg so=0 eo=19 --after: TOKEN: pixma so=0 eo=5 TOKEN: a so=6 eo=7 TOKEN: b so=8 eo=9 TOKEN: c so=10 eo=11 TOKEN: d so=12 eo=13 TOKEN: e so=14 eo=15 TOKEN: f so=16 eo=17 TOKEN: g so=18 eo=19 TOKEN: pixmaabcdefg so=0 eo=19
          Hide
          Erick Erickson added a comment -

          This seems like a fairly straight-forward patch code-change wise, but I confess I know nothing about this code. So if someone who does can take a glance at the actual changes (three lines total, and unit tests, cool!) and render an opinion on Steffan's note about the collation issue is something to be concerned about or not I can alter the failing test and get this into the code.

          Show
          Erick Erickson added a comment - This seems like a fairly straight-forward patch code-change wise, but I confess I know nothing about this code. So if someone who does can take a glance at the actual changes (three lines total, and unit tests, cool!) and render an opinion on Steffan's note about the collation issue is something to be concerned about or not I can alter the failing test and get this into the code.
          Hide
          Steffen Elberg Godskesen added a comment -

          This patch passes James' new unit tests, but fails testCollate() in org.apache.solr.handler.component.SpellCheckComponentTest, since the collation "pixmaa-a-b-c-d-e-f-g" is now returned for the query "pixma-a-b-c-d-e-f-g" with the word "pixmaa" in the index. The test expects the collation "pixmaa" to be returned.

          I'm not really in a position to decide which behavior is correct. The new behavior passes James' tests and fixes the StringIndexOutOfBoundsException, but may deviate enough from the current behavior to cause problems for existing users.

          Show
          Steffen Elberg Godskesen added a comment - This patch passes James' new unit tests, but fails testCollate() in org.apache.solr.handler.component.SpellCheckComponentTest, since the collation "pixmaa-a-b-c-d-e-f-g" is now returned for the query "pixma-a-b-c-d-e-f-g" with the word "pixmaa" in the index. The test expects the collation "pixmaa" to be returned. I'm not really in a position to decide which behavior is correct. The new behavior passes James' tests and fixes the StringIndexOutOfBoundsException, but may deviate enough from the current behavior to cause problems for existing users.
          Hide
          James Dyer added a comment -

          This patch contains a failing unit test, based on Steffan's config files.

          Show
          James Dyer added a comment - This patch contains a failing unit test, based on Steffan's config files.
          Hide
          Steffen Elberg Godskesen added a comment -

          We seem to be hitting this bug in in 4.0 also. I've attached the simplest (that I could come up with) config, schema and document that enables me to reproduce the exception on the latest nightly build (from https://builds.apache.org/job/Solr-trunk/lastSuccessfulBuild/artifact/artifacts/apache-solr-4.0-2011-11-16_08-54-59.tgz)

          To reproduce:

          1. Start a Solr instance using the attached schema.xml and solrconfig.xml
          2. Add the attached document.xml to the index
          3. Query for hypenated-wotd with spellchecking on and collation on (e.g. http://localhost:8983/solr/select?&q=hypenated-wotd&spellcheck=true&spellcheck.collate=true)

          This will log the following exception (very similar to the one above, but included for completeness)

          Nov 16, 2011 11:18:33 AM org.apache.solr.core.SolrCore execute
          INFO: [] webapp=/solr path=/select params={spellcheck.collate=true&spellcheck=true&q=hypenated-wotd} hits=0 status=500 QTime=34 
          Nov 16, 2011 11:18:33 AM org.apache.solr.common.SolrException log
          SEVERE: java.lang.StringIndexOutOfBoundsException: String index out of range: -4
          	at java.lang.AbstractStringBuilder.replace(AbstractStringBuilder.java:797)
          	at java.lang.StringBuilder.replace(StringBuilder.java:271)
          	at org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:131)
          	at org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:70)
          	at org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:177)
          	at org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:154)
          	at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194)
          	at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
          	at org.apache.solr.core.SolrCore.execute(SolrCore.java:1475)
          	at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:353)
          	at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:248)
          	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
          	at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
          	at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
          	at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
          	at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
          	at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
          	at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
          	at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
          	at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
          	at org.mortbay.jetty.Server.handle(Server.java:326)
          	at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
          	at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
          	at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
          	at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
          	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
          	at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
          	at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
          
          Show
          Steffen Elberg Godskesen added a comment - We seem to be hitting this bug in in 4.0 also. I've attached the simplest (that I could come up with) config, schema and document that enables me to reproduce the exception on the latest nightly build (from https://builds.apache.org/job/Solr-trunk/lastSuccessfulBuild/artifact/artifacts/apache-solr-4.0-2011-11-16_08-54-59.tgz ) To reproduce: Start a Solr instance using the attached schema.xml and solrconfig.xml Add the attached document.xml to the index Query for hypenated-wotd with spellchecking on and collation on (e.g. http://localhost:8983/solr/select?&q=hypenated-wotd&spellcheck=true&spellcheck.collate=true ) This will log the following exception (very similar to the one above, but included for completeness) Nov 16, 2011 11:18:33 AM org.apache.solr.core.SolrCore execute INFO: [] webapp=/solr path=/select params={spellcheck.collate=true&spellcheck=true&q=hypenated-wotd} hits=0 status=500 QTime=34 Nov 16, 2011 11:18:33 AM org.apache.solr.common.SolrException log SEVERE: java.lang.StringIndexOutOfBoundsException: String index out of range: -4 at java.lang.AbstractStringBuilder.replace(AbstractStringBuilder.java:797) at java.lang.StringBuilder.replace(StringBuilder.java:271) at org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:131) at org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:70) at org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:177) at org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:154) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1475) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:353) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:248) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
          Hide
          Jan Høydahl added a comment - - edited

          I see this issue in 1.4 with query "Irano-Hind" and spellcheck w/collate. However, I cannot reproduce in 3.1, so my issue was probably SOLR-1630 related.

          Sure you're on 3.1? Can you describe closer what you do, what field type you use, how you setup spellcheck etc?

          Show
          Jan Høydahl added a comment - - edited I see this issue in 1.4 with query "Irano-Hind" and spellcheck w/collate. However, I cannot reproduce in 3.1, so my issue was probably SOLR-1630 related. Sure you're on 3.1? Can you describe closer what you do, what field type you use, how you setup spellcheck etc?
          Hide
          Hoss Man added a comment -

          the stack trace is different, but based on the fact that it has to do with using spellcheck.collate and "-" in the query this smells like it might be realted to SOLR-1630

          Show
          Hoss Man added a comment - the stack trace is different, but based on the fact that it has to do with using spellcheck.collate and "-" in the query this smells like it might be realted to SOLR-1630
          Hide
          Hoss Man added a comment -

          Moved original stack trace out of description for brevity...

          The error is :
          HTTP ERROR 500
          
          Problem accessing /solr/select. Reason:
          
              String index out of range: -1
          
          java.lang.StringIndexOutOfBoundsException: String index out of range: -1
          	at java.lang.AbstractStringBuilder.replace(AbstractStringBuilder.java:797)
          	at java.lang.StringBuilder.replace(StringBuilder.java:271)
          	at org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:131)
          	at org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:69)
          	at org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:179)
          	at org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:157)
          	at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194)
          	at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
          	at org.apache.solr.core.SolrCore.execute(SolrCore.java:1360)
          	at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356)
          	at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252)
          	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
          	at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
          	at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
          	at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
          	at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
          	at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
          	at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
          	at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
          	at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
          	at org.mortbay.jetty.Server.handle(Server.java:326)
          	at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
          	at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
          	at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
          	at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
          	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
          	at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
          	at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
          
          
          Show
          Hoss Man added a comment - Moved original stack trace out of description for brevity... The error is : HTTP ERROR 500 Problem accessing /solr/select. Reason: String index out of range: -1 java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.AbstractStringBuilder.replace(AbstractStringBuilder.java:797) at java.lang.StringBuilder.replace(StringBuilder.java:271) at org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:131) at org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:69) at org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:179) at org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:157) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1360) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450) at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230) at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152) at org.mortbay.jetty.Server.handle(Server.java:326) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
          Hide
          Thomas Gambier added a comment -

          More investigation :

          I've located that spellchecker collate function is the trouble.

          http://localhost:8983/solr/spell?q=cle_frbr%3A"LYSROUGE1149-73190"&spellcheck=true&spellcheck.collate=true
          The query failed with the same error as above.

          http://localhost:8983/solr/spell?q=cle_frbr%3A"LYSROUGE1149-73190"&spellcheck=true
          This query works fine.

          Show
          Thomas Gambier added a comment - More investigation : I've located that spellchecker collate function is the trouble. http://localhost:8983/solr/spell?q=cle_frbr%3A "LYSROUGE1149-73190"&spellcheck=true&spellcheck.collate=true The query failed with the same error as above. http://localhost:8983/solr/spell?q=cle_frbr%3A "LYSROUGE1149-73190"&spellcheck=true This query works fine.

            People

            • Assignee:
              Erick Erickson
              Reporter:
              Thomas Gambier
            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development