Solr
  1. Solr
  2. SOLR-6845

Add buildOnStartup option for suggesters

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.1, 6.0
    • Component/s: None
    • Labels:
      None

      Description

      SOLR-6679 was filed to track the investigation into the following problem...

      The stock solrconfig provides a bad experience with a large index... start up Solr and it will spin at 100% CPU for minutes, unresponsive, while it apparently builds a suggester index.
      ...
      This is what I did:
      1) indexed 10M very small docs (only takes a few minutes).
      2) shut down Solr
      3) start up Solr and watch it be unresponsive for over 4 minutes!

      I didn't even use any of the fields specified in the suggester config and I never called the suggest request handler.

      ..but ultimately focused on removing/disabling the suggester from the sample configs.

      Opening this new issue to focus on actually trying to identify the root problem & fix it.

      1. SOLR-6845_solrconfig.patch
        1 kB
        Varun Thacker
      2. SOLR-6845.patch
        26 kB
        Tomás Fernández Löbbe
      3. SOLR-6845.patch
        15 kB
        Tomás Fernández Löbbe
      4. SOLR-6845.patch
        12 kB
        Tomás Fernández Löbbe
      5. tests-failures.txt
        295 kB
        Shalin Shekhar Mangar

        Issue Links

          Activity

          Hide
          Varun Thacker added a comment -

          Excerpt from the logs -

          16160 [coreLoadExecutor-5-thread-2] INFO  org.apache.solr.handler.component.SpellCheckComponent  – Initializing spell checkers
          16161 [coreLoadExecutor-5-thread-2] INFO  org.apache.solr.spelling.DirectSolrSpellChecker  – init: {name=default,field=text,classname=solr.DirectSolrSpellChecker,distanceMeasure=internal,accuracy=0.5,maxEdits=2,minPrefix=1,maxInspections=5,minQueryLength=4,maxQueryFrequency=0.01}
          16162 [coreLoadExecutor-5-thread-2] INFO  org.apache.solr.handler.component.SpellCheckComponent  – No queryConverter defined, using default converter
          16164 [coreLoadExecutor-5-thread-2] INFO  org.apache.solr.handler.component.SuggestComponent  – Initializing SuggestComponent
          16164 [coreLoadExecutor-5-thread-2] INFO  org.apache.solr.spelling.suggest.SolrSuggester  – init: {name=mySuggester,lookupImpl=FuzzyLookupFactory,dictionaryImpl=DocumentDictionaryFactory,field=cat,weightField=price,suggestAnalyzerFieldType=string}
          16164 [coreLoadExecutor-5-thread-2] INFO  org.apache.solr.spelling.suggest.SolrSuggester  – Dictionary loaded with params: {name=mySuggester,lookupImpl=FuzzyLookupFactory,dictionaryImpl=DocumentDictionaryFactory,field=cat,weightField=price,suggestAnalyzerFieldType=string}
          16164 [coreLoadExecutor-5-thread-2] INFO  org.apache.solr.common.cloud.ZkStateReader  – Load collection config from:/collections/solr6606
          16166 [coreLoadExecutor-5-thread-2] INFO  org.apache.solr.common.cloud.ZkStateReader  – path=/collections/solr6606 configName=solr6606 specified config exists in ZooKeeper
          16186 [coreLoadExecutor-5-thread-2] INFO  org.apache.solr.handler.ReplicationHandler  – Commits will be reserved for  10000
          16187 [searcherExecutor-6-thread-1] INFO  org.apache.solr.core.SolrCore  – QuerySenderListener sending requests to Searcher@6b1b4cac[solr6606_shard1_replica1] main{StandardDirectoryReader(segments_5q:2567:nrt _9g(4.10.2):C794000 _io(4.10.2):C760000 _sf(4.10.2):C796000 _yk(4.10.2):C543000 _ze(4.10.2):C72000 _zf(4.10.2):C1000 _zg(4.10.2):C2000 _zh(4.10.2):C3000 _zi(4.10.2):C3000 _zj(4.10.2):C2121 _zk(4.10.2):C2879 _zl(4.10.2):C3000 _zm(4.10.2):C2000)}
          16226 [searcherExecutor-6-thread-1] INFO  org.apache.solr.core.SolrCore  – [solr6606_shard1_replica1] webapp=null path=null params={event=firstSearcher&q=static+firstSearcher+warming+in+solrconfig.xml&distrib=false} hits=0 status=0 QTime=39 
          16227 [searcherExecutor-7-thread-1] INFO  org.apache.solr.core.SolrCore  – [collection1] webapp=null path=null params={event=firstSearcher&q=static+firstSearcher+warming+in+solrconfig.xml&distrib=false} hits=0 status=0 QTime=66 
          16227 [searcherExecutor-6-thread-1] INFO  org.apache.solr.core.SolrCore  – QuerySenderListener done.
          16227 [searcherExecutor-7-thread-1] INFO  org.apache.solr.core.SolrCore  – QuerySenderListener done.
          16227 [searcherExecutor-6-thread-1] INFO  org.apache.solr.handler.component.SpellCheckComponent  – Loading spell index for spellchecker: default
          16227 [searcherExecutor-7-thread-1] INFO  org.apache.solr.handler.component.SpellCheckComponent  – Loading spell index for spellchecker: default
          16228 [searcherExecutor-6-thread-1] INFO  org.apache.solr.handler.component.SpellCheckComponent  – Loading spell index for spellchecker: wordbreak
          16228 [searcherExecutor-7-thread-1] INFO  org.apache.solr.handler.component.SpellCheckComponent  – Loading spell index for spellchecker: wordbreak
          16228 [searcherExecutor-6-thread-1] INFO  org.apache.solr.handler.component.SuggestComponent  – Loading suggester index for: mySuggester
          16228 [searcherExecutor-7-thread-1] INFO  org.apache.solr.handler.component.SuggestComponent  – Loading suggester index for: mySuggester
          16229 [searcherExecutor-7-thread-1] INFO  org.apache.solr.spelling.suggest.SolrSuggester  – reload()
          16228 [searcherExecutor-6-thread-1] INFO  org.apache.solr.spelling.suggest.SolrSuggester  – reload()
          16229 [searcherExecutor-6-thread-1] INFO  org.apache.solr.spelling.suggest.SolrSuggester  – build()
          16229 [searcherExecutor-7-thread-1] INFO  org.apache.solr.spelling.suggest.SolrSuggester  – build()
          16249 [searcherExecutor-7-thread-1] INFO  org.apache.solr.core.SolrCore  – [collection1] Registered new searcher Searcher@2c8633e1[collection1] main{StandardDirectoryReader(segments_1:1:nrt)}
          

          The SuggestComponent init's correctly. It's only when the firstSearcher event gets fired that the spellchecker and the suggester gets built. This is where the problem lies.

          We should just comment out the <str name="q">static firstSearcher warming in solrconfig.xml</str> query from the firstSearcher query list, just as how the queries are commented out from the newSearcher event listener.

          We should also add a comment here saying that adding queries here does the following internally and would lead to longer load times.
          1. Builds the suggester, spellchecker and any other components which register itself to new searcher events.
          2. When an entry contains a sort/facet/function query and the field is not an docValues field then it UnInverts the fields and puts it into the FieldCache
          3. Adds entries to the other Solr caches.

          The multiple reload and build commands is because I have 2 cores on my machine.

          Show
          Varun Thacker added a comment - Excerpt from the logs - 16160 [coreLoadExecutor-5-thread-2] INFO org.apache.solr.handler.component.SpellCheckComponent – Initializing spell checkers 16161 [coreLoadExecutor-5-thread-2] INFO org.apache.solr.spelling.DirectSolrSpellChecker – init: {name= default ,field=text,classname=solr.DirectSolrSpellChecker,distanceMeasure=internal,accuracy=0.5,maxEdits=2,minPrefix=1,maxInspections=5,minQueryLength=4,maxQueryFrequency=0.01} 16162 [coreLoadExecutor-5-thread-2] INFO org.apache.solr.handler.component.SpellCheckComponent – No queryConverter defined, using default converter 16164 [coreLoadExecutor-5-thread-2] INFO org.apache.solr.handler.component.SuggestComponent – Initializing SuggestComponent 16164 [coreLoadExecutor-5-thread-2] INFO org.apache.solr.spelling.suggest.SolrSuggester – init: {name=mySuggester,lookupImpl=FuzzyLookupFactory,dictionaryImpl=DocumentDictionaryFactory,field=cat,weightField=price,suggestAnalyzerFieldType=string} 16164 [coreLoadExecutor-5-thread-2] INFO org.apache.solr.spelling.suggest.SolrSuggester – Dictionary loaded with params: {name=mySuggester,lookupImpl=FuzzyLookupFactory,dictionaryImpl=DocumentDictionaryFactory,field=cat,weightField=price,suggestAnalyzerFieldType=string} 16164 [coreLoadExecutor-5-thread-2] INFO org.apache.solr.common.cloud.ZkStateReader – Load collection config from:/collections/solr6606 16166 [coreLoadExecutor-5-thread-2] INFO org.apache.solr.common.cloud.ZkStateReader – path=/collections/solr6606 configName=solr6606 specified config exists in ZooKeeper 16186 [coreLoadExecutor-5-thread-2] INFO org.apache.solr.handler.ReplicationHandler – Commits will be reserved for 10000 16187 [searcherExecutor-6-thread-1] INFO org.apache.solr.core.SolrCore – QuerySenderListener sending requests to Searcher@6b1b4cac[solr6606_shard1_replica1] main{StandardDirectoryReader(segments_5q:2567:nrt _9g(4.10.2):C794000 _io(4.10.2):C760000 _sf(4.10.2):C796000 _yk(4.10.2):C543000 _ze(4.10.2):C72000 _zf(4.10.2):C1000 _zg(4.10.2):C2000 _zh(4.10.2):C3000 _zi(4.10.2):C3000 _zj(4.10.2):C2121 _zk(4.10.2):C2879 _zl(4.10.2):C3000 _zm(4.10.2):C2000)} 16226 [searcherExecutor-6-thread-1] INFO org.apache.solr.core.SolrCore – [solr6606_shard1_replica1] webapp= null path= null params={event=firstSearcher&q= static +firstSearcher+warming+in+solrconfig.xml&distrib= false } hits=0 status=0 QTime=39 16227 [searcherExecutor-7-thread-1] INFO org.apache.solr.core.SolrCore – [collection1] webapp= null path= null params={event=firstSearcher&q= static +firstSearcher+warming+in+solrconfig.xml&distrib= false } hits=0 status=0 QTime=66 16227 [searcherExecutor-6-thread-1] INFO org.apache.solr.core.SolrCore – QuerySenderListener done. 16227 [searcherExecutor-7-thread-1] INFO org.apache.solr.core.SolrCore – QuerySenderListener done. 16227 [searcherExecutor-6-thread-1] INFO org.apache.solr.handler.component.SpellCheckComponent – Loading spell index for spellchecker: default 16227 [searcherExecutor-7-thread-1] INFO org.apache.solr.handler.component.SpellCheckComponent – Loading spell index for spellchecker: default 16228 [searcherExecutor-6-thread-1] INFO org.apache.solr.handler.component.SpellCheckComponent – Loading spell index for spellchecker: wordbreak 16228 [searcherExecutor-7-thread-1] INFO org.apache.solr.handler.component.SpellCheckComponent – Loading spell index for spellchecker: wordbreak 16228 [searcherExecutor-6-thread-1] INFO org.apache.solr.handler.component.SuggestComponent – Loading suggester index for : mySuggester 16228 [searcherExecutor-7-thread-1] INFO org.apache.solr.handler.component.SuggestComponent – Loading suggester index for : mySuggester 16229 [searcherExecutor-7-thread-1] INFO org.apache.solr.spelling.suggest.SolrSuggester – reload() 16228 [searcherExecutor-6-thread-1] INFO org.apache.solr.spelling.suggest.SolrSuggester – reload() 16229 [searcherExecutor-6-thread-1] INFO org.apache.solr.spelling.suggest.SolrSuggester – build() 16229 [searcherExecutor-7-thread-1] INFO org.apache.solr.spelling.suggest.SolrSuggester – build() 16249 [searcherExecutor-7-thread-1] INFO org.apache.solr.core.SolrCore – [collection1] Registered new searcher Searcher@2c8633e1[collection1] main{StandardDirectoryReader(segments_1:1:nrt)} The SuggestComponent init's correctly. It's only when the firstSearcher event gets fired that the spellchecker and the suggester gets built. This is where the problem lies. We should just comment out the <str name="q">static firstSearcher warming in solrconfig.xml</str> query from the firstSearcher query list, just as how the queries are commented out from the newSearcher event listener. We should also add a comment here saying that adding queries here does the following internally and would lead to longer load times. 1. Builds the suggester, spellchecker and any other components which register itself to new searcher events. 2. When an entry contains a sort/facet/function query and the field is not an docValues field then it UnInverts the fields and puts it into the FieldCache 3. Adds entries to the other Solr caches. The multiple reload and build commands is because I have 2 cores on my machine.
          Hide
          Hoss Man added a comment -

          We should just comment out the <str name="q">static firstSearcher warming in solrconfig.xml</str> query ...

          This is still side stepping the root problem this issue was opened to address: why is hte /suggest handler so damn slow?

          We don't need more baind-aid fixes that can be applied to the techproducts example configs to work-arround whatever fundemental problem exists - SOLR-6679 already applied enough of a band-aid for that.

          what we need is to understand:

          • why the hell is this suggester so damn slow to build it's dictionary even when the fields aren't used at all in the index?
          • why the does this suggester auto-register a firstSearcher/newSearcher event listener to build the dict w/o there being any sort of configuration option indicating that the solr-admin has requested it to build on firstSearcher (or on every searcher open if that's what/why this is happening)
          Show
          Hoss Man added a comment - We should just comment out the <str name="q">static firstSearcher warming in solrconfig.xml</str> query ... This is still side stepping the root problem this issue was opened to address: why is hte /suggest handler so damn slow? We don't need more baind-aid fixes that can be applied to the techproducts example configs to work-arround whatever fundemental problem exists - SOLR-6679 already applied enough of a band-aid for that. what we need is to understand: why the hell is this suggester so damn slow to build it's dictionary even when the fields aren't used at all in the index? why the does this suggester auto-register a firstSearcher/newSearcher event listener to build the dict w/o there being any sort of configuration option indicating that the solr-admin has requested it to build on firstSearcher (or on every searcher open if that's what/why this is happening)
          Hide
          Tomás Fernández Löbbe added a comment -

          why the hell is this suggester so damn slow to build it's dictionary even when the fields aren't used at all in the index?

          I understand the reason of this is that the suggester still iterates across all docs in the index, trying to get the stored content of those fields. Even if the field is never present, this needs to be done. Most of the time in my tests is spent in InputIterator.next()

          why does this suggester auto-register a firstSearcher/newSearcher event listener to build the dict w/o there being any sort of configuration option indicating that the solr-admin has requested it to build on firstSearcher (or on every searcher open if that's what/why this is happening)

          That's right, the suggester is building on startup and there is no way to disable this. We should add an option to enable/disable this, maybe a "buildOnStartup" conf option that could be "false" by default. I think it should still "load" the stored suggesters when present.

          Show
          Tomás Fernández Löbbe added a comment - why the hell is this suggester so damn slow to build it's dictionary even when the fields aren't used at all in the index? I understand the reason of this is that the suggester still iterates across all docs in the index, trying to get the stored content of those fields. Even if the field is never present, this needs to be done. Most of the time in my tests is spent in InputIterator.next() why does this suggester auto-register a firstSearcher/newSearcher event listener to build the dict w/o there being any sort of configuration option indicating that the solr-admin has requested it to build on firstSearcher (or on every searcher open if that's what/why this is happening) That's right, the suggester is building on startup and there is no way to disable this. We should add an option to enable/disable this, maybe a "buildOnStartup" conf option that could be "false" by default. I think it should still "load" the stored suggesters when present.
          Hide
          Tomás Fernández Löbbe added a comment -

          Trying to add some unit tests to this feature I found another issue. SuggestComponent and SpellcheckComponent rely on a firstSearcherListener to load (and in this case, also build) some structures. These firstSearcherListeners are registered on SolrCoreAware.inform(), however the first searcher listener task is only added to the queue of warming tasks if there is at least one listener registered at the time of the first searcher creation (before SolrCoreAware.inform() is ever called). See

          SolrCore.java
                  if (currSearcher == null && firstSearcherListeners.size() > 0) {
                    future = searcherExecutor.submit(new Callable() {
                      @Override
                      public Object call() throws Exception {
                        try {
                          for (SolrEventListener listener : firstSearcherListeners) {
                            listener.newSearcher(newSearcher, null);
                          }
                        } catch (Throwable e) {
                          SolrException.log(log, null, e);
                          if (e instanceof Error) {
                            throw (Error) e;
                          }
                        }
                        return null;
                      }
                    });
                  }
          

          I'll create a new Jira for this

          Show
          Tomás Fernández Löbbe added a comment - Trying to add some unit tests to this feature I found another issue. SuggestComponent and SpellcheckComponent rely on a firstSearcherListener to load (and in this case, also build) some structures. These firstSearcherListeners are registered on SolrCoreAware.inform() , however the first searcher listener task is only added to the queue of warming tasks if there is at least one listener registered at the time of the first searcher creation (before SolrCoreAware.inform() is ever called). See SolrCore.java if (currSearcher == null && firstSearcherListeners.size() > 0) { future = searcherExecutor.submit( new Callable() { @Override public Object call() throws Exception { try { for (SolrEventListener listener : firstSearcherListeners) { listener.newSearcher(newSearcher, null ); } } catch (Throwable e) { SolrException.log(log, null , e); if (e instanceof Error) { throw (Error) e; } } return null ; } }); } I'll create a new Jira for this
          Hide
          Tomás Fernández Löbbe added a comment -

          Created SOLR-6864

          Show
          Tomás Fernández Löbbe added a comment - Created SOLR-6864
          Hide
          Tomás Fernández Löbbe added a comment -

          Here is a patch to add buildOnStartup. With buildOnStartup=false and buildOnCommit=true, the suggester is loaded if it already exist, but not built if it doesn't on startup.
          The problem I see is that in regular core reload, searchers are open in a way that the "newSearcherListeners" are invoked, this means that even if buildOnStartup=false and buildOnCommit=true, a core reload would build the suggester if not found

          Show
          Tomás Fernández Löbbe added a comment - Here is a patch to add buildOnStartup. With buildOnStartup=false and buildOnCommit=true, the suggester is loaded if it already exist, but not built if it doesn't on startup. The problem I see is that in regular core reload, searchers are open in a way that the "newSearcherListeners" are invoked, this means that even if buildOnStartup=false and buildOnCommit=true, a core reload would build the suggester if not found
          Hide
          Tomás Fernández Löbbe added a comment -

          I see now, the problem is that core reload creates a new core and then opens a new searcher, so reloading a core calls the firstSearcherListener and then the newSearcherListener.

          Show
          Tomás Fernández Löbbe added a comment - I see now, the problem is that core reload creates a new core and then opens a new searcher, so reloading a core calls the firstSearcherListener and then the newSearcherListener.
          Hide
          Tomás Fernández Löbbe added a comment -

          In this patch, I added a “buildOnStartup” for the suggester that defaults to false. If this is not set, the suggester will load a dictionary if it exists, but won’t create it if it doesn’t.

          "buildOnStartup" will also build the suggester in case of a core reload. Users should be aware that in both, “SolrCloud mode” and with a “master-slave” setup, Solr may trigger a core reload internally, and if “buildOnStartup” is set, the core reload will build the suggester (if it's not being stored). Unlike with the current code a core reload won’t trigger a “buildOnCommit” event.

          A side note is that, even if “useColdSearcher” is set to “false”, in case of a core reload the suggester may be built after the first searcher is registered, the reason for this is that it is built using the second searcher created in the core reload process.

          Show
          Tomás Fernández Löbbe added a comment - In this patch, I added a “buildOnStartup” for the suggester that defaults to false. If this is not set, the suggester will load a dictionary if it exists, but won’t create it if it doesn’t. "buildOnStartup" will also build the suggester in case of a core reload. Users should be aware that in both, “SolrCloud mode” and with a “master-slave” setup, Solr may trigger a core reload internally, and if “buildOnStartup” is set, the core reload will build the suggester (if it's not being stored). Unlike with the current code a core reload won’t trigger a “buildOnCommit” event. A side note is that, even if “useColdSearcher” is set to “false”, in case of a core reload the suggester may be built after the first searcher is registered, the reason for this is that it is built using the second searcher created in the core reload process.
          Hide
          Tomás Fernández Löbbe added a comment -

          Here is a new patch. I saw that we were trying to load the suggester twice, once on the Suggester init and once in the searcher listener. I removed the load from the searcher listener.
          I also changed the default of the "buildOnStartup", instead of being always "false", it defaults to true if no suggester dictionary exists (if the storeDir is not set or if it's set but the suggester was never built). This is compatible with the behavior in 4.10.
          Unfortunately I didn't have time to put this change in 5.0, there are no major compatibility issues, the only one I see is that "reload" no longer builds if the dictionary is not present. I think this is correct and should be the behavior of 6.x, for 5.x I'll make the reload action build if no dictionary is present.

          Show
          Tomás Fernández Löbbe added a comment - Here is a new patch. I saw that we were trying to load the suggester twice, once on the Suggester init and once in the searcher listener. I removed the load from the searcher listener. I also changed the default of the "buildOnStartup", instead of being always "false", it defaults to true if no suggester dictionary exists (if the storeDir is not set or if it's set but the suggester was never built). This is compatible with the behavior in 4.10. Unfortunately I didn't have time to put this change in 5.0, there are no major compatibility issues, the only one I see is that "reload" no longer builds if the dictionary is not present. I think this is correct and should be the behavior of 6.x, for 5.x I'll make the reload action build if no dictionary is present.
          Hide
          ASF subversion and git services added a comment -

          Commit 1653410 from Tomás Fernández Löbbe in branch 'dev/trunk'
          [ https://svn.apache.org/r1653410 ]

          SOLR-6845: Add a ''buildOnStartup'' option for suggesters. (Tomás Fernández Löbbe)

          Show
          ASF subversion and git services added a comment - Commit 1653410 from Tomás Fernández Löbbe in branch 'dev/trunk' [ https://svn.apache.org/r1653410 ] SOLR-6845 : Add a ''buildOnStartup'' option for suggesters. (Tomás Fernández Löbbe)
          Hide
          ASF subversion and git services added a comment -

          Commit 1653414 from Tomás Fernández Löbbe in branch 'dev/trunk'
          [ https://svn.apache.org/r1653414 ]

          SOLR-6845: Remove enable=false from the suggest request handler in the techproducts sample config. It is OK to use (and copy/paste this configuration) with buildOnStartup=false

          Show
          ASF subversion and git services added a comment - Commit 1653414 from Tomás Fernández Löbbe in branch 'dev/trunk' [ https://svn.apache.org/r1653414 ] SOLR-6845 : Remove enable=false from the suggest request handler in the techproducts sample config. It is OK to use (and copy/paste this configuration) with buildOnStartup=false
          Hide
          ASF subversion and git services added a comment -

          Commit 1653443 from Tomás Fernández Löbbe in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1653443 ]

          SOLR-6845: Add a ''buildOnStartup'' option for suggesters

          Show
          ASF subversion and git services added a comment - Commit 1653443 from Tomás Fernández Löbbe in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1653443 ] SOLR-6845 : Add a ''buildOnStartup'' option for suggesters
          Hide
          Tomás Fernández Löbbe added a comment -

          Changed summary to reflect the actual change done

          Show
          Tomás Fernández Löbbe added a comment - Changed summary to reflect the actual change done
          Hide
          Shalin Shekhar Mangar added a comment -

          I just saw a local failure on trunk on org.apache.solr.handler.component.SuggestComponentTest.testDefaultBuildOnStartupStoredDict. The logs are attached and the stack trace is:

            2> 786070 T7047 oas.SolrTestCaseJ4.assertQ ERROR REQUEST FAILED: xpath=//lst[@name='suggest']/lst[@name='suggest_doc_default_startup']/lst[@name='example']/int[@name='numFound'][.='0']
            2>            xml response was: <?xml version="1.0" encoding="UTF-8"?>
            2>    <response>
            2>    <lst name="responseHeader"><int name="status">0</int><int name="QTime">5</int></lst><lst name="suggest"><lst name="suggest_doc_default_startup"><lst name="example"><int name="numFound">2</int><arr name="suggestions"><lst><str name="term">example inputdata</str><long name="weight">45</long><str name="payload"/></lst><lst><str name="term">example data</str><long name="weight">40</long><str name="payload"/></lst></arr></lst></lst></lst>
            2>    </response>
            2>
            2>            request was:qt=/suggest&suggest.q=example&suggest.count=2&suggest.dictionary=suggest_doc_default_startup&wt=xml
            2> 786071 T7047 oasc.SolrException.log ERROR REQUEST FAILED: qt=/suggest&suggest.q=example&suggest.count=2&suggest.dictionary=suggest_doc_default_startup&wt=xml:java.lang.RuntimeException: REQUEST FAILED: xpath=//lst[@name='suggest']/lst[@name='suggest_doc_default_startup']/lst[@name='example']/int[@name='numFound'][.='0']
            2>            xml response was: <?xml version="1.0" encoding="UTF-8"?>
            2>    <response>
            2>    <lst name="responseHeader"><int name="status">0</int><int name="QTime">5</int></lst><lst name="suggest"><lst name="suggest_doc_default_startup"><lst name="example"><int name="numFound">2</int><arr name="suggestions"><lst><str name="term">example inputdata</str><long name="weight">45</long><str name="payload"/></lst><lst><str name="term">example data</str><long name="weight">40</long><str name="payload"/></lst></arr></lst></lst></lst>
            2>    </response>
            2>
            2>            request was:qt=/suggest&suggest.q=example&suggest.count=2&suggest.dictionary=suggest_doc_default_startup&wt=xml
            2>            at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:741)
            2>            at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:715)
            2>            at org.apache.solr.handler.component.SuggestComponentTest.testDefaultBuildOnStartupStoredDict(SuggestComponentTest.java:257)
            2>            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          
          ant test  -Dtestcase=SuggestComponentTest -Dtests.method=testDefaultBuildOnStartupStoredDict -Dtests.seed=1AE9946D9D16B26E -Dtests.slow=true -Dtests.locale=en -Dtests.timezone=Asia/Istanbul -Dtests.asserts=true -Dtests.file.encoding=ISO-8859-1
          

          I tried a few times but couldn't reproduce it.

          Show
          Shalin Shekhar Mangar added a comment - I just saw a local failure on trunk on org.apache.solr.handler.component.SuggestComponentTest.testDefaultBuildOnStartupStoredDict. The logs are attached and the stack trace is: 2> 786070 T7047 oas.SolrTestCaseJ4.assertQ ERROR REQUEST FAILED: xpath= //lst[@name='suggest']/lst[@name='suggest_doc_default_startup']/lst[@name='example']/ int [@name='numFound'][.='0'] 2> xml response was: <?xml version= "1.0" encoding= "UTF-8" ?> 2> <response> 2> <lst name= "responseHeader" >< int name= "status" >0</ int >< int name= "QTime" >5</ int ></lst><lst name= "suggest" ><lst name= "suggest_doc_default_startup" ><lst name= "example" >< int name= "numFound" >2</ int ><arr name= "suggestions" ><lst><str name= "term" >example inputdata</str>< long name= "weight" >45</ long ><str name= "payload" /></lst><lst><str name= "term" >example data</str>< long name= "weight" >40</ long ><str name= "payload" /></lst></arr></lst></lst></lst> 2> </response> 2> 2> request was:qt=/suggest&suggest.q=example&suggest.count=2&suggest.dictionary=suggest_doc_default_startup&wt=xml 2> 786071 T7047 oasc.SolrException.log ERROR REQUEST FAILED: qt=/suggest&suggest.q=example&suggest.count=2&suggest.dictionary=suggest_doc_default_startup&wt=xml:java.lang.RuntimeException: REQUEST FAILED: xpath= //lst[@name='suggest']/lst[@name='suggest_doc_default_startup']/lst[@name='example']/ int [@name='numFound'][.='0'] 2> xml response was: <?xml version= "1.0" encoding= "UTF-8" ?> 2> <response> 2> <lst name= "responseHeader" >< int name= "status" >0</ int >< int name= "QTime" >5</ int ></lst><lst name= "suggest" ><lst name= "suggest_doc_default_startup" ><lst name= "example" >< int name= "numFound" >2</ int ><arr name= "suggestions" ><lst><str name= "term" >example inputdata</str>< long name= "weight" >45</ long ><str name= "payload" /></lst><lst><str name= "term" >example data</str>< long name= "weight" >40</ long ><str name= "payload" /></lst></arr></lst></lst></lst> 2> </response> 2> 2> request was:qt=/suggest&suggest.q=example&suggest.count=2&suggest.dictionary=suggest_doc_default_startup&wt=xml 2> at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:741) 2> at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:715) 2> at org.apache.solr.handler.component.SuggestComponentTest.testDefaultBuildOnStartupStoredDict(SuggestComponentTest.java:257) 2> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ant test -Dtestcase=SuggestComponentTest -Dtests.method=testDefaultBuildOnStartupStoredDict -Dtests.seed=1AE9946D9D16B26E -Dtests.slow= true -Dtests.locale=en -Dtests.timezone=Asia/Istanbul -Dtests.asserts= true -Dtests.file.encoding=ISO-8859-1 I tried a few times but couldn't reproduce it.
          Hide
          Tomás Fernández Löbbe added a comment -

          I'll take a look

          Show
          Tomás Fernández Löbbe added a comment - I'll take a look
          Hide
          Tomás Fernández Löbbe added a comment -

          Also a fail in Jenkins: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2523/
          I can reproduce this fail by making the build slow. I'll commit a fix

          Show
          Tomás Fernández Löbbe added a comment - Also a fail in Jenkins: https://builds.apache.org/job/Lucene-Solr-Tests-5.x-Java7/2523/ I can reproduce this fail by making the build slow. I'll commit a fix
          Hide
          ASF subversion and git services added a comment -

          Commit 1653784 from Tomás Fernández Löbbe in branch 'dev/trunk'
          [ https://svn.apache.org/r1653784 ]

          SOLR-6845: Suggester tests start new cores instead of reloading

          Show
          ASF subversion and git services added a comment - Commit 1653784 from Tomás Fernández Löbbe in branch 'dev/trunk' [ https://svn.apache.org/r1653784 ] SOLR-6845 : Suggester tests start new cores instead of reloading
          Hide
          ASF subversion and git services added a comment -

          Commit 1653789 from Tomás Fernández Löbbe in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1653789 ]

          SOLR-6845: Suggester tests start new cores instead of reloading

          Show
          ASF subversion and git services added a comment - Commit 1653789 from Tomás Fernández Löbbe in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1653789 ] SOLR-6845 : Suggester tests start new cores instead of reloading
          Hide
          Tomás Fernández Löbbe added a comment -

          I changed the test to only start new cores instead of reloading as a temporary fix to avoid noise in Jenkins. I'll continue working to make the test work with reload again.

          Show
          Tomás Fernández Löbbe added a comment - I changed the test to only start new cores instead of reloading as a temporary fix to avoid noise in Jenkins. I'll continue working to make the test work with reload again.
          Hide
          ASF subversion and git services added a comment -

          Commit 1654710 from Tomás Fernández Löbbe in branch 'dev/trunk'
          [ https://svn.apache.org/r1654710 ]

          SOLR-6845: Fixed Suggester's buildOnStartup in core reload and improved tests

          Show
          ASF subversion and git services added a comment - Commit 1654710 from Tomás Fernández Löbbe in branch 'dev/trunk' [ https://svn.apache.org/r1654710 ] SOLR-6845 : Fixed Suggester's buildOnStartup in core reload and improved tests
          Hide
          ASF subversion and git services added a comment -

          Commit 1654714 from Tomás Fernández Löbbe in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1654714 ]

          SOLR-6845: Fixed Suggester's buildOnStartup in core reload and improved tests

          Show
          ASF subversion and git services added a comment - Commit 1654714 from Tomás Fernández Löbbe in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1654714 ] SOLR-6845 : Fixed Suggester's buildOnStartup in core reload and improved tests
          Hide
          Tomás Fernández Löbbe added a comment -

          Didn't see any Jenkins failures of this test since the last commit. I'll mark it as resolved

          Show
          Tomás Fernández Löbbe added a comment - Didn't see any Jenkins failures of this test since the last commit. I'll mark it as resolved
          Hide
          Varun Thacker added a comment -

          Hi Tomás Fernández Löbbe ,

          Minor documentation nit - In SuggestComponent , the comment on the BUILD_ON_STARTUP_LABEL variable needs to be modified to - "SolrConfig label to identify boolean value to build suggesters on startup"

          Show
          Varun Thacker added a comment - Hi Tomás Fernández Löbbe , Minor documentation nit - In SuggestComponent , the comment on the BUILD_ON_STARTUP_LABEL variable needs to be modified to - "SolrConfig label to identify boolean value to build suggesters on startup"
          Hide
          Tomás Fernández Löbbe added a comment -

          Thanks Varun Thacker, fixed

          Show
          Tomás Fernández Löbbe added a comment - Thanks Varun Thacker , fixed
          Hide
          Erick Erickson added a comment -

          Tomás Fernández Löbbe If I were to apply this patch to 4.10 do you see any inherent problems? I merged all the changes last night and it seems to run and index docs, the buildOnStartup parameter seems to be respected etc. Running unit tests now.

          My responsibility if I try this of course, just asking if yo know of any reason this is a Bad Idea.

          Thanks!

          Show
          Erick Erickson added a comment - Tomás Fernández Löbbe If I were to apply this patch to 4.10 do you see any inherent problems? I merged all the changes last night and it seems to run and index docs, the buildOnStartup parameter seems to be respected etc. Running unit tests now. My responsibility if I try this of course, just asking if yo know of any reason this is a Bad Idea. Thanks!
          Hide
          Tomás Fernández Löbbe added a comment -

          No issues that I can think of, let's backport it.

          Show
          Tomás Fernández Löbbe added a comment - No issues that I can think of, let's backport it.
          Hide
          Erick Erickson added a comment -

          Reopening for inclusion in 4.10.5

          Show
          Erick Erickson added a comment - Reopening for inclusion in 4.10.5
          Hide
          Erick Erickson added a comment -

          Decided not to back-port, it was more complex than I thought.

          Show
          Erick Erickson added a comment - Decided not to back-port, it was more complex than I thought.
          Hide
          Stephan Lagraulet added a comment -

          We will be glad to have this in 4.10.5 or at least on the 5.0 branch.
          Is there too much effort to backport this issue or is it risky?
          We can contribute if needed because we really need this option to avoid very long startup times.

          Show
          Stephan Lagraulet added a comment - We will be glad to have this in 4.10.5 or at least on the 5.0 branch. Is there too much effort to backport this issue or is it risky? We can contribute if needed because we really need this option to avoid very long startup times.
          Hide
          Varun Thacker added a comment - - edited

          Hi Tomás Fernández Löbbe,

          We should remove this comment from the solrconfig.xml file right? I have made the required change in the ref guide as well.

          Show
          Varun Thacker added a comment - - edited Hi Tomás Fernández Löbbe , We should remove this comment from the solrconfig.xml file right? I have made the required change in the ref guide as well.
          Hide
          Tomás Fernández Löbbe added a comment -

          We should remove this comment from the solrconfig.xml file right?

          I was sure I had remove the comment! Thanks for pointing that out. I'll remove it

          I have made the required change in the ref guide as well.

          Thanks, I didn't do this initially because by the time I did this change the docs were still about 5.0, but now was a good time to fix that.

          Show
          Tomás Fernández Löbbe added a comment - We should remove this comment from the solrconfig.xml file right? I was sure I had remove the comment! Thanks for pointing that out. I'll remove it I have made the required change in the ref guide as well. Thanks, I didn't do this initially because by the time I did this change the docs were still about 5.0, but now was a good time to fix that.
          Hide
          ASF subversion and git services added a comment -

          Commit 1670183 from Tomás Fernández Löbbe in branch 'dev/trunk'
          [ https://svn.apache.org/r1670183 ]

          SOLR-6845: Updated SuggestComponent comments in techproducts example configset

          Show
          ASF subversion and git services added a comment - Commit 1670183 from Tomás Fernández Löbbe in branch 'dev/trunk' [ https://svn.apache.org/r1670183 ] SOLR-6845 : Updated SuggestComponent comments in techproducts example configset
          Hide
          ASF subversion and git services added a comment -

          Commit 1670186 from Tomás Fernández Löbbe in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1670186 ]

          SOLR-6845: Updated SuggestComponent comments in techproducts example configset

          Show
          ASF subversion and git services added a comment - Commit 1670186 from Tomás Fernández Löbbe in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1670186 ] SOLR-6845 : Updated SuggestComponent comments in techproducts example configset
          Hide
          Tomás Fernández Löbbe added a comment -

          Varun, I can't find the changes made to the ref guide, where did you make them?

          Show
          Tomás Fernández Löbbe added a comment - Varun, I can't find the changes made to the ref guide, where did you make them?
          Hide
          Varun Thacker added a comment -

          Hi Tomas,

          I meant I removed the sentence which went like - the suggester is disabled by default I didn't add the documentation for this param.

          Anyways thanks for catching that. Here is what I wrote up for it -

          buildOnStartup: If true then the lookup data structure will be built when Solr starts or when the core is reloaded. If this parameter is not specified, the suggester will check if the lookup data structure is present on disk. If yes then it won't load up on startup. Enabling this to true could lead to the core talking longer to load as the suggester data structure needs to be built

          Feel free to edit it and add it to the ref guide else I'll add it tomorrow.

          Show
          Varun Thacker added a comment - Hi Tomas, I meant I removed the sentence which went like - the suggester is disabled by default I didn't add the documentation for this param. Anyways thanks for catching that. Here is what I wrote up for it - buildOnStartup: If true then the lookup data structure will be built when Solr starts or when the core is reloaded. If this parameter is not specified, the suggester will check if the lookup data structure is present on disk. If yes then it won't load up on startup. Enabling this to true could lead to the core talking longer to load as the suggester data structure needs to be built Feel free to edit it and add it to the ref guide else I'll add it tomorrow.
          Hide
          Tomás Fernández Löbbe added a comment -

          Added your paragraph with some modifications to the ref guide. Feel free to edit it there.

          Show
          Tomás Fernández Löbbe added a comment - Added your paragraph with some modifications to the ref guide. Feel free to edit it there.
          Hide
          Timothy Potter added a comment -

          Bulk close after 5.1 release

          Show
          Timothy Potter added a comment - Bulk close after 5.1 release

            People

            • Assignee:
              Erick Erickson
              Reporter:
              Hoss Man
            • Votes:
              1 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development