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
--
