You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Peter Keegan <pe...@gmail.com> on 2006/06/02 01:23:07 UTC

Re: Nio File Caching & Performance Test

My search process is using MMapDirectory on a read-only index via:

-Dorg.apache.lucene.FSDirectory.class=org.apache.lucene.store.MMapDirectory

Another indexing process is building the next version of the index in a
different directory. When it's time to switch to the new index, the search
process closes the old IndexSearcher, MultiReader (2) and FSDirectories (2)
and opens the new index. Subsequently, attempts to delete the old index
files fail because there are apparently still references to them from the
old MMapDirectory (the deletes succeed when using FSDirectory).

My understanding is that the file mapping is valid until the underlying
buffer is garbage-collected. Is there a deterministic way of releasing the
old memory mapped files so that they can be deleted sucessfully?

Thanks,
Peter

RE: Nio File Caching & Performance Test

Posted by Robert Engels <re...@ix.netcom.com>.
Not that I know how. I think you are at the mercy of the GC. The files will
get deleted on the next merge though (most likely). 

-----Original Message-----
From: Peter Keegan [mailto:peterlkeegan@gmail.com] 
Sent: Thursday, June 01, 2006 6:23 PM
To: java-dev@lucene.apache.org; rengels@ix.netcom.com
Subject: Re: Nio File Caching & Performance Test

My search process is using MMapDirectory on a read-only index via:

-Dorg.apache.lucene.FSDirectory.class=org.apache.lucene.store.MMapDirectory

Another indexing process is building the next version of the index in a
different directory. When it's time to switch to the new index, the search
process closes the old IndexSearcher, MultiReader (2) and FSDirectories (2)
and opens the new index. Subsequently, attempts to delete the old index
files fail because there are apparently still references to them from the
old MMapDirectory (the deletes succeed when using FSDirectory).

My understanding is that the file mapping is valid until the underlying
buffer is garbage-collected. Is there a deterministic way of releasing the
old memory mapped files so that they can be deleted sucessfully?

Thanks,
Peter


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org