This explains some of it: http://wiki.apache.org/solr/SolrCaching
So, there is normally only a single searcher handing around. When a new searcher is opened, it is opened and warmed in the "background" so there are two searchers for the duration of warming. A new searcher is only opened on an explicit <commit> command... Solr does not attempt to detect when an index has changed (doing so could result in inconsistencies, and worse performance). If explicit commits are done fast enough, and warming takes long enough, one can get into the situation where there are multiple searchers warming in the background at the same time. We currently hande this by ensuring clients behave. -Yonik On 10/23/06, Paul Waite <[EMAIL PROTECTED]> wrote:
Hi chaps, I currently have a lucene app. which is a daemon listening on a port for XML requests and servicing these. I'm intending to switch to using Solr in the near(ish) future, but have a question. In my daemon, for servicing incoming search requests I manage index Searchers in a cache via the following cases:. 1) there's is no cached Searcher: - create a new Searcher and cache it 2) there is a cached Searcher, and index has NOT been updated since it was created: - use cached Searcher. 3) there is a cached Searcher, and index HAS been updated since it was created: - if the cache limit is not reached flag current Searcher as "old", create new Searcher and cache it, else if cache limit reached return current Searcher. Searchers flagged as "old" get retired as soon as they finish servicing any existing requests. The question I have regarding Solr is: does it do something similar? If so can someone please describe the process - thanks. I am particularly interested in a provision for a cap on creation of new Searchers, as described in (3) above. As my index has grown, and the system updates it frequently, I found that an open-ended approach to creation of new Searchers in the event of index change was leading to out-of-memory errors. Cheers, Paul.
