Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-9154

Config API does not work when adding a component with DirectSolrSpellChecker

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.4, 7.0
    • Component/s: config-api, spellchecker
    • Labels:
      None

      Description

      When trying to add a DirectSolrSpellchecker using the Config API (JSON), there seems to be a loss of information w.r.t the param types. The accuracy field, only in this specific case needs to be defined as a float it seems. While this is possible when updating the solrconfig,xml directly, the field type (float) can not be specified using JSON.

      Here are the steps to reproduce this issue:

      #Bootstrapping
      bin/solr start -c
      bin/solr create -c foo
      bin/post -c foo example/exampledocs/books.csv
      
      #Add spell checker - This would hang and the logs contain recurring exceptions as mentioned below
      curl http://localhost:8983/solr/foo/config -H 'Content-type:application/json' -d '{"update-searchcomponent": {"name":"spellcheck",       "class":"solr.SpellCheckComponent",       "spellchecker":[         { "name":"text_index_dictionary", "field":"text", "classname":"solr.DirectSolrSpellChecker", "distanceMeasure":"org.apache.lucene.search.spell.LevensteinDistance", "accuracy":0.5, "maxEdits":2, "minPrefix":1, "maxInspections":5, "minQueryLength":4, "maxQueryFrequency":0.001, "thresholdTokenFrequency":0.01}]}}'
      

      Log:

      2016-05-24 04:08:44.371 ERROR (SolrConfigHandler-refreshconf) [c:foo s:shard1 r:core_node1 x:foo_shard1_replica1] o.a.s.h.SolrConfigHandler Unable to refresh conf 
      org.apache.solr.common.SolrException: Unable to reload core [foo_shard1_replica1]
      	at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:944)
      	at org.apache.solr.core.SolrCore.lambda$getConfListener$7(SolrCore.java:2510)
      	at org.apache.solr.handler.SolrConfigHandler$Command$1.run(SolrConfigHandler.java:218)
      Caused by: org.apache.solr.common.SolrException: java.lang.Double cannot be cast to java.lang.Float
      	at org.apache.solr.core.SolrCore.<init>(SolrCore.java:773)
      	at org.apache.solr.core.SolrCore.reload(SolrCore.java:462)
      	at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:938)
      
      1. SOLR-9154.patch
        4 kB
        Anshum Gupta
      2. SOLR-9154.patch
        3 kB
        Anshum Gupta

        Activity

        Hide
        anshumg Anshum Gupta added a comment -

        Seems like all assignments have issues in the init method for this class. This was the first one so this is all that got hit and logged.
        I'll work on a patch.

        Show
        anshumg Anshum Gupta added a comment - Seems like all assignments have issues in the init method for this class. This was the first one so this is all that got hit and logged. I'll work on a patch.
        Hide
        anshumg Anshum Gupta added a comment -

        I'm not purely convinced with the patch but this works. If someone has a better idea, feel free to suggest, else I'll commit this after adding a test.

        Show
        anshumg Anshum Gupta added a comment - I'm not purely convinced with the patch but this works. If someone has a better idea, feel free to suggest, else I'll commit this after adding a test.
        Hide
        alexandre.drouin Alex D added a comment - - edited

        Would it be possible to convert the config variable to a SolrParams (e.g.: using SolrParams.toSolrParams)? This way you could use get* methods instead of parsing the string yourself.

        Show
        alexandre.drouin Alex D added a comment - - edited Would it be possible to convert the config variable to a SolrParams (e.g.: using SolrParams.toSolrParams)? This way you could use get* methods instead of parsing the string yourself.
        Hide
        dsmiley David Smiley added a comment -

        Would it be possible to convert the config variable to a SolrParams (e.g.: using SolrParams.toSolrParams)? This way you could use get* methods instead of parsing the string yourself.

        +1 – I've often felt the annoying differences between NamedList and SolrParams for the simple name=value cases. A convenience method on NamedList toSolrParams() would make this more obvious. These initializers could be updated to use SolrParams instead. That's obviously a bigger refactoring & scope change than just the spellchecker, but it seems inevitable something broader than just this patch should get done as it's inevitable this same bug pattern will appear again!

        Another possible change, possibly simpler, is to have NamedList have getFloatVal, getDoubleVal, getStringVal, getIntVal, getLongVal. It already has getBooleanArg which is named poorly (IMO). And then, update everyone to use these rather than getVal. These added methods could do float/double conversions, treating them equivalently. Maybe String parsing too.

        Show
        dsmiley David Smiley added a comment - Would it be possible to convert the config variable to a SolrParams (e.g.: using SolrParams.toSolrParams)? This way you could use get* methods instead of parsing the string yourself. +1 – I've often felt the annoying differences between NamedList and SolrParams for the simple name=value cases. A convenience method on NamedList toSolrParams() would make this more obvious. These initializers could be updated to use SolrParams instead. That's obviously a bigger refactoring & scope change than just the spellchecker, but it seems inevitable something broader than just this patch should get done as it's inevitable this same bug pattern will appear again! Another possible change, possibly simpler, is to have NamedList have getFloatVal, getDoubleVal, getStringVal, getIntVal, getLongVal. It already has getBooleanArg which is named poorly (IMO). And then, update everyone to use these rather than getVal. These added methods could do float/double conversions, treating them equivalently. Maybe String parsing too.
        Hide
        anshumg Anshum Gupta added a comment -

        I think this is better, but I'm not sure if for the sake of this patch, we should expose params.

        Show
        anshumg Anshum Gupta added a comment - I think this is better, but I'm not sure if for the sake of this patch, we should expose params .
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit 93562da610bf8756351be7720c69872bc1cea727 in lucene-solr's branch refs/heads/master from anshum
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=93562da ]

        SOLR-9154: Fix DirectSolrSpellChecker to work when added through the Config API

        Show
        jira-bot ASF subversion and git services added a comment - Commit 93562da610bf8756351be7720c69872bc1cea727 in lucene-solr's branch refs/heads/master from anshum [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=93562da ] SOLR-9154 : Fix DirectSolrSpellChecker to work when added through the Config API
        Hide
        jira-bot ASF subversion and git services added a comment -

        Commit fb39e397dbd17fea68f5d46baf80f5af8f5b59d0 in lucene-solr's branch refs/heads/branch_6x from anshum
        [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fb39e39 ]

        SOLR-9154: Fix DirectSolrSpellChecker to work when added through the Config API

        Show
        jira-bot ASF subversion and git services added a comment - Commit fb39e397dbd17fea68f5d46baf80f5af8f5b59d0 in lucene-solr's branch refs/heads/branch_6x from anshum [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=fb39e39 ] SOLR-9154 : Fix DirectSolrSpellChecker to work when added through the Config API

          People

          • Assignee:
            anshumg Anshum Gupta
            Reporter:
            anshumg Anshum Gupta
          • Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development