> > Could this be due to caching? I have tried to disable all in my solrconfig.
If you mean Solr caches ? NO . Solr caches live the life of the searcher. So new searcher, new caches ( possibly warmed with updated results) . If you mean your application caching or browser caching, you should verify, i assume you have control on that. Cheers 2015-07-21 6:02 GMT+01:00 Bhawna Asnani <bhawna.asn...@gmail.com>: > Thanks, I tried turning off auto softCommits but that didn't help much. > Still seeing stale results every now and then. Also load on the server very > light. We are running this just on a test server with one or two users. I > don't see any warning in logs whole doing softCommits and it says it > successfully opened new searcher and registered it as main searcher. Could > this be due to caching? I have tried to disable all in my solrconfig. > > Sent from my iPhone > > > On Jul 20, 2015, at 12:16 PM, Shawn Heisey <apa...@elyograg.org> wrote: > > > >> On 7/20/2015 9:29 AM, Bhawna Asnani wrote: > >> Thanks for your suggestions. The requirement is still the same , to be > >> able to make a change to some solr documents and be able to see it on > >> subsequent search/facet calls. > >> I am using softCommit with waitSearcher=true. > >> > >> Also I am sending reads/writes to a single solr node only. > >> I have tried disabling caches and warmup time in logs is '0' but every > >> once in a while I do get the document just updated with stale data. > >> > >> I went through lucene documentation and it seems opening the > >> IndexReader with the IndexWriter should make the changes visible to > >> the reader. > >> > >> I checked solr logs no errors. I see this in logs each time > >> 'Registered new searcher Searcher@xxxxx' even before searches that had > >> the stale document. > >> > >> I have attached my solrconfig.xml for reference. > > > > Your attachment made it through the mailing list processing. Most > > don't, I'm surprised. Some thoughts: > > > > maxBooleanClauses has been set to 400000. This is a lot. If you > > actually need a setting that high, then you are sending some MASSIVE > > queries, which probably means that your Solr install is exceptionally > > busy running those queries. > > > > If the server is fairly busy, then you should increase maxTime on > > autoCommit. I use a value of five minutes (300000) ... and my server is > > NOT very busy most of the time. A commit with openSearcher set to false > > is relatively fast, but it still has somewhat heavy CPU, memory, and > > disk I/O resource requirements. > > > > You have autoSoftCommit set to happen after five seconds. If updates > > happen frequently or run for very long, this is potentially a LOT of > > committing and opening new searchers. I guess it's better than trying > > for one second, but anything more frequent than once a minute is likely > > to get you into trouble unless the system load is extremely light ... > > but as already discussed, your system load is probably not light. > > > > For the kind of Near Real Time setup you have mentioned, where you want > > to do one or more updates, commit, and then query for the changes, you > > probably should completely remove autoSoftCommit from the config and > > *only* open new searchers with explicit soft commits. Let autoCommit > > (with a maxTime of 1 to 5 minutes) handle durability concerns. > > > > A lot of pieces in your config file are set to depend on java system > > properties just like the example does, but since we do not know what > > system properties have been set, we can't tell for sure what those parts > > of the config are doing. > > > > Thanks, > > Shawn > > > -- -------------------------- Benedetti Alessandro Visiting card - http://about.me/alessandro_benedetti Blog - http://alexbenedetti.blogspot.co.uk "Tyger, tyger burning bright In the forests of the night, What immortal hand or eye Could frame thy fearful symmetry?" William Blake - Songs of Experience -1794 England
