decref() decrements the reference count and closes the searcher when it reaches 0 (no more users). Forcing it to close at the point you did is unsafe since other threads may still be using that searcher. The real issue lies somewhere else - either a stuck thread, or some code that is not decrementing the reference when it's done. It's most likely the latter.
We need to get to the root cause. Can you open a JIRA bug for this? -Yonik http://www.lucidimagination.com On Fri, Mar 13, 2009 at 12:39 PM, Marc Sturlese <marc.sturl...@gmail.com> wrote: > > Hey Yonik, > I tested the last nightly build and still happens... but I have solved it! I > tell you my solution, it seems to be working well but just want to be sure > that it doesn't have any bad effects as for me this is one of the most > complicated parts of the Solr source (the fact of dealing with multiple > indexsearchers in a syncronized way). > I noticed that in the SolrCore.java, there's a part in the function > getSearcher where there is a comment saying: > > // we are all done with the old searcher we used > // for warming... > > And after that the code is: > if (currSearcherHolderF!=null) currSearcherHolderF.decref(); > > The problem here is that this old SolrIndexSearcher is never closed and > never removed from _searchers > What I have done: > > if (currSearcherHolderF!=null){ > > currSearcherHolderF.get().close(); //close SolrIndexSearcher proper > currSearcherHolderF.decref(); > _searchers.remove(); //remove the > } > > Doing that... if I do a "lsof | grep tomcat" will see that tomcat is not > holding deleted files anymore (as indexsearcher was proper close) and the > _searchers var will not accumulate infinite references... > It sorts the problem in the stats screen aswell... after 5 full-imports it > just shows one IndexSearcher > What do you think?
