OK I opened https://issues.apache.org/jira/browse/LUCENE-2762 for this issue.
Mike On Fri, Nov 12, 2010 at 5:21 PM, Michael McCandless <luc...@mikemccandless.com> wrote: > Are you using compound file format (the default)? > > If you turn that off (just for this test) do you still see that > IndexWriter is holding open the files (35 in your example) after you > close all readers? > > I've found a case, only with compound file, where IndexWriter holds > open a SegmentReader on the pre-compound-file files... I'm working on > a test case & fix. > > Mike > > On Fri, Nov 12, 2010 at 5:49 AM, Thomas Rewig <tre...@mufin.com> wrote: >> Hello, >> >> I use the searcherManager for LiveIndexing. With watch -n 60 "lsof | grep >> indexname | grep deleted | wc -l" I see the number of deleted file handles. >> The number of handles fluctuates during the indexing. 0 -> 35 -> 53 -> 135 >> -> 40 -> 85 ... Uwe said that this is expected because segments are still >> referenced by the open IndexReaders, but files were already deleted by >> IndexWriter. >> >> But something puzzles me: >> >> Let's say we have a deleted file handle number of 85. If I switch the >> NearRealTime Searcher to the readOnlySearcher the file handle number is >> still 85. If i close afterwards the no more used indexwriter, the number >> drops to 35. I think that means, that the indexwriter referenced deleted >> files that are not referenced by the readers. It seems, that with every >> commit the number of deleted file handles (which maybe are "caused" by the >> indexwriter) grows. >> Is that possible and if yes why does the indexwriter do it? Is there a max >> Value of deleted handles an IndexWriter could own, because I don't want to >> chrash the system because of too much open filehandles? >> >> Thanks in advance. >> Thomas >> -- >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
