> the merge settings (and maybe the MergeScheduler) to ensure that your > pathalogical worst case scenerio (ie: a really big merge) doens't block > your commits.
ConcurrentMergeScheduler should be handling the thread priorities more intelligently in Lucene 3.1. https://issues.apache.org/jira/browse/LUCENE-2164 On Wed, Apr 21, 2010 at 3:55 PM, Chris Hostetter <hossman_luc...@fucit.org> wrote: > > : We don't mind having an occasional long delay between commiting data and > : being able to find that data, as long as the average is somewhere south of a > : second or so, and Lucene's NRS looks like it will provides that level of > : 'realtimeness'. > > an average 500ms "lag until visible" is totally feasible with Solr 1.4 -- > provided you aren't using replication (or are using super fast > replication) and provided you don't need a lot of cache warming (which > requires a trade off in terms of how fast the searches themselves are) > > given all that, the one thing you might need to worry about is tweaking > the merge settings (and maybe the MergeScheduler) to ensure that your > pathalogical worst case scenerio (ie: a really big merge) doens't block > your commits. > > > > > -Hoss > >
