Search code examples
javasolrsolrcloud

Apache Solr filtering not working but possible to retrieve by id

Background: We have a 3-node solr cloud that was migrated to docker. It works as expected, however, for new data that is inserted, it can only be retrieved by id. Once we try to use filters, it doesn't show. Note that old data can still be filtered without any issues.

The database is is used via spring-boot crud-like application.

More background:

The app and the solr were migrated by another person and I have inherited the codebase recently so I am not familiar in much detail about the implementation and am still digging and debugging. The nodes were migrated as-is (the data was copied into a docker mount).

What I have so far:

I have checked the logs of all the solr nodes and see the following happening when making the calls to the application:

Filtering:

2019-02-22 14:17:07.525 INFO  (qtp15xxxxx-15) [c:content_api s:shard1 r:core_node1 x:content_api_shard1_replica0] o.a.s.c.S.Request
[content_api_shard1_replica0]  
webapp=/solr path=/select 
params=
{q=*:*&start=0&fq=id-lws-ttf:127103&fq=active-boo-ttf:(true)&fq=(publish-date-tda-ttf:[*+TO+2019-02-22T15:17:07Z]+OR+(*:*+NOT+publish-date-tda-ttf:[*+TO+*]))AND+(expiration-date-tda-ttf:[2019-02-22T15:17:07Z+TO+*]+OR+(*:*+NOT+expiration-date-tda-ttf:[*+TO+*]))&sort=create-date-tda-ttf+desc&rows=10&wt=javabin&version=2} 
hits=0 status=0 QTime=37

Get by ID:

2019-02-22 14:16:56.441 INFO  (qtp15xxxxxx-16) [c:content_api s:shard1 r:core_node1 x:content_api_shard1_replica0] o.a.s.c.S.Request
[content_api_shard1_replica0]  
webapp=/solr path=/get params={ids=https://example.com/app/contents/127103/middle-east&wt=javabin&version=2} 
status=0 QTime=0

Disclaimer:

I am an absolute beginner in working with Solr and am going through documentation ATM in order to get better insight into the nuts and bolts.

Assumptions and WIP:

  • The person who migrated it told me that only the data was copied, not the configuration. I have acquired the old config files (/opt/solr/server/solr/configsets/) and am trying to compare to the new ones. But the assumption is that the configs were defaults.

  • The old version was 6.4.2 and the new one is 6.6.5 (not sure that this could be the issue)

Is there something obvious that we are missing here? What is superconfusing is the fact that the data can be retrieved by id AND that the OLD data can be filtered

Update:

  • After some researching, I have to say that I have excluded the config issue because when I inspect the configuration from the admin UI, I see the correct configuration.
  • Also, another weird behavior is that the data can be queried after some time (like more than 5 days). I can see that because I run the query from the UI and order it by descending creation date. From there, I can see my tests that I was not just days ago

Relevant commit config part:

 <autoCommit> 
   <maxTime>${solr.autoCommit.maxTime:15000}</maxTime> 
   <openSearcher>false</openSearcher> 
 </autoCommit>

 <autoSoftCommit> 
   <maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime> 
 </autoSoftCommit>

More config output from the admin endpoint:

config:{  
   znodeVersion:0,
   luceneMatchVersion:"org.apache.lucene.util.Version:6.0.1",
   updateHandler:{  
      indexWriter:{  
         closeWaitsForMerges:true
      },
      commitWithin:{  
         softCommit:true
      },
      autoCommit:{  
         maxDocs:-1,
         maxTime:15000,
         openSearcher:false
      },
      autoSoftCommit:{  
         maxDocs:-1,
         maxTime:-1
      }
   },
   query:{  
      useFilterForSortedQuery:false,
      queryResultWindowSize:20,
      queryResultMaxDocsCached:200,
      enableLazyFieldLoading:true,
      maxBooleanClauses:1024,
      filterCache:{  
         autowarmCount:"0",
         size:"512",
         initialSize:"512",
         class:"solr.FastLRUCache",
         name:"filterCache"
      },
      queryResultCache:{  
         autowarmCount:"0",
         size:"512",
         initialSize:"512",
         class:"solr.LRUCache",
         name:"queryResultCache"
      },
      documentCache:{  
         autowarmCount:"0",
         size:"512",
         initialSize:"512",
         class:"solr.LRUCache",
         name:"documentCache"
      },
:{  
         size:"10000",
         showItems:"-1",
         initialSize:"10",
         name:"fieldValueCache"
      }
   },
...
Solution

  • According to your examples you're only retrieving the document when you're querying the realtime get endpoint - i.e. /get. This endpoint returns documents by querying by id, even if the document hasn't been commited to the index or a new searcher has been opened.

    A new searcher has to be created before any changes to the index become visible to the regular search endpoints, since the old searcher will still use the old index files for searching. If a new searcher isn't created, the stale content will still be returned. This matches the behaviour you're seeing, where you're not opening any new searchers, and content becomes visible when the searcher is recycled for other reasons (possibly because of restarts/another explicit commit/merges/optimizes/etc.).

    Your example configuration shows that the autoSoftCommit is disabled, while the regular autoCommit is set to not open a new searcher (and thus, no new content is shown). I usually recommend disabling this feature and instead relying on using commitWithin in the URL as it allows greater configurability for different types of data, and allows you to ask for a new searcher to be opened within at least x seconds since data has been added. The default behaviour for commitWithin is that a new searcher will be opened after the commit has happened.