Eric, Thanks for the detailed response...I have two follow up questions :
1) Is there currently a configuration setting in Solr that will trigger the first option you mentioned ? Which is to not serve any searches until tlogs are played. If not, since instances shutting down abruptly is not very uncommon, would a JIRA to implement this configuration be warranted? 2) We have a setup with moderate indexing rate and moderate search rate. Currently the auto commit interval is 10 mins. What should be a recommended hard commit interval for such a setup? Our concern with going too low on that autoCommit interval (with openSearcher=false) is the number of segments that would drastically increase, eventually causing merges,slower searches etc. Thanks, Rahul On Fri, Mar 8, 2019 at 12:08 PM Erick Erickson <erickerick...@gmail.com> wrote: > Yes, you’ll get stale values. There’s no way I know of to change that, > it’s a fundamental result of Lucene’s design. > > There’s a “segment_n” file that contains pointers to the current valid > segments. When a commit happens, segments are closed and the very last > operation is to update that file. > > In the abnormal termination case, that file has not been updated with docs > that are in the tlog. So when Solr opens a searcher, it has no record at > all of any new segments created since the last hard commit. So there are > only two choices: > > 1> refuse to seve any searches at all > 2> allow searches on the last snapshot of the index while the tlog replays > > The latter is the choice we’ve made and I agree with it. While > theoretically you could refuse to open a searcher while the tlog was > replaying, I’d rather get some results than none at all. > > Especially when this only happens when Solr is abnormally terminated. > > You can mitigate the time frame here by setting your hard commit interval > to, say, 15 seconds, which should be the upper bound of getting stale docs > when the tlog is replayed. > > It’s also good practice to have the autocommit interval relatively short > for a variety of reasons, not the least of which is that it’ll grow > infinitely until a hard commit happens. > > Best, > Erick > > > On Mar 8, 2019, at 8:48 AM, Rahul Goswami <rahul196...@gmail.com> wrote: > > > > What I am observing is that Solr is fully started up even before it has > > finished playing the tlog. In the logs I see that a searcher is > registered > > first and the "Log replay finished" appears later. During that time if I > > search, I do get stale values. Below are the log lines that I captured : > > > > WARN - 2019-03-08 16:33:42.126; [ x:techproducts] > > org.apache.solr.update.UpdateLog$LogReplayer; Starting log replay > > > tlog{file=C:\Work\Solr\solr-7.2.1\Installation\solr-7.2.1\example\techproducts\solr\techproducts\data\tlog\tlog.0000000000000000009 > > refcount=2} active=false starting pos=0 inSortedOrder=false > > INFO - 2019-03-08 16:33:42.141; [ x:techproducts] > > org.apache.solr.core.SolrCore; [techproducts] webapp=null path=null > > > params={q=static+firstSearcher+warming+in+solrconfig.xml&distrib=false&event=firstSearcher} > > hits=3 status=0 QTime=37 > > INFO - 2019-03-08 16:33:42.157; [ x:techproducts] > > org.apache.solr.core.QuerySenderListener; QuerySenderListener done. > > INFO - 2019-03-08 16:33:42.157; [ x:techproducts] > > > org.apache.solr.handler.component.SpellCheckComponent$SpellCheckerListener; > > Loading spell index for spellchecker: default > > INFO - 2019-03-08 16:33:42.157; [ x:techproducts] > > > org.apache.solr.handler.component.SpellCheckComponent$SpellCheckerListener; > > Loading spell index for spellchecker: wordbreak > > INFO - 2019-03-08 16:33:42.157; [ x:techproducts] > > org.apache.solr.core.SolrCore; [techproducts] Registered new searcher > > Searcher@63c5631[techproducts] > > > main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_0(7.2.1):C32/1:delGen=1) > > Uninverting(_5(7.2.1):C1)))} > > INFO - 2019-03-08 16:34:07.373; [ x:techproducts] > > org.apache.solr.core.SolrCore; [techproducts] webapp=/solr path=/select > > params={q=id:SP2514N&wt=json&_=1552062352063} hits=1 status=0 QTime=2 > > INFO - 2019-03-08 16:34:08.818; [ x:techproducts] > > org.apache.solr.core.SolrCore; [techproducts] webapp=/solr path=/select > > params={q=id:SP2514N&wt=json&_=1552062352063} hits=1 status=0 QTime=1 > > INFO - 2019-03-08 16:34:14.422; [ x:techproducts] > > org.apache.solr.update.DirectUpdateHandler2; start > > > commit{flags=2,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false} > > INFO - 2019-03-08 16:34:16.353; [ x:techproducts] > > org.apache.solr.core.SolrCore; [techproducts] webapp=/solr path=/select > > params={q=id:SP2514N&wt=json&_=1552062352063} hits=1 status=0 QTime=1 > > INFO - 2019-03-08 16:34:18.948; [ x:techproducts] > > org.apache.solr.update.SolrIndexWriter; Calling setCommitData with > > IW:org.apache.solr.update.SolrIndexWriter@266e1192 > commitCommandVersion:0 > > INFO - 2019-03-08 16:34:19.040; [ x:techproducts] > > org.apache.solr.search.SolrIndexSearcher; Opening > > [Searcher@5c6044f1[techproducts] > > main] > > INFO - 2019-03-08 16:34:19.040; [ x:techproducts] > > org.apache.solr.update.DirectUpdateHandler2; end_commit_flush > > INFO - 2019-03-08 16:34:19.040; [ x:techproducts] > > org.apache.solr.core.QuerySenderListener; QuerySenderListener sending > > requests to Searcher@5c6044f1[techproducts] > > > main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_0(7.2.1):C32/1:delGen=1) > > Uninverting(_6(7.2.1):C1)))} > > INFO - 2019-03-08 16:34:19.040; [ x:techproducts] > > org.apache.solr.core.QuerySenderListener; QuerySenderListener done. > > INFO - 2019-03-08 16:34:19.040; [ x:techproducts] > > org.apache.solr.core.SolrCore; [techproducts] Registered new searcher > > Searcher@5c6044f1[techproducts] > > > main{ExitableDirectoryReader(UninvertingDirectoryReader(Uninverting(_0(7.2.1):C32/1:delGen=1) > > Uninverting(_6(7.2.1):C1)))} > > INFO - 2019-03-08 16:34:19.056; [ x:techproducts] > > > org.apache.solr.update.processor.LogUpdateProcessorFactory$LogUpdateProcessor; > > [techproducts] {add=[SP2514N (1627455755076501504)]} 0 36923 > > WARN - 2019-03-08 16:34:19.056; [ x:techproducts] > > org.apache.solr.update.UpdateLog$LogReplayer; Log replay finished. > > recoveryInfo=RecoveryInfo{adds=1 deletes=0 deleteByQuery=0 errors=0 > > positionOfStart=0} > > INFO - 2019-03-08 16:34:23.523; [ x:techproducts] > > org.apache.solr.core.SolrCore; [techproducts] webapp=/solr path=/select > > params={q=id:SP2514N&wt=json&_=1552062352063} hits=1 status=0 QTime=1 > > > > On Thu, Mar 7, 2019 at 11:36 PM Zheng Lin Edwin Yeo < > edwinye...@gmail.com> > > wrote: > > > >> Hi, > >> > >> Do you mean that when you startup Solr, it will automatically do the > search > >> request even before the Solr is fully started up? > >> > >> Regards, > >> Edwin > >> > >> > >> On Fri, 8 Mar 2019 at 10:13, Rahul Goswami <rahul196...@gmail.com> > wrote: > >> > >>> Hello Solr gurus, > >>> > >>> I am using Solr 7.2.1 (non-SolrCloud). I have a situation where Solr > got > >>> killed before it could commit updates to the disk resulting in log > replay > >>> on startup. During this interval, I observe that a searcher is opened > >> even > >>> before log replay has finished, resulting in some stale results, which > in > >>> turn has a cascading effect on other parts of the application. Is > there a > >>> setting in Solr which would prevent Solr from serving search requests > >>> before log replay has finished? > >>> > >>> Thanks, > >>> Rahul > >>> > >> > >