lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Keegan" <peterlkee...@gmail.com>
Subject Re: MMapDirectory vs RAMDirectory
Date Mon, 05 Jun 2006 13:54:40 GMT
I'm reposting this from java-dev to java-user for greater exposure.

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 still references to them from the old
MMapDirectory (in contrast, the deletes succeed when using FSDirectory).

There is no 'unmap' method, so my understanding is that the file mapping is
valid until the underlying buffer is garbage-collected. However, forcing the
gc doesn't help.

I found this bug listed at Sun:
http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=4724038
Synopsis: (fs) Add unmap method to MappedByteBuffer)

The file deletes don't fail on Linux, but I'm wondering if there is still a
memory leak?

Has anyone discovered a way of releasing the old memory mapped files so that
they can be deleted sucessfully on Windows? My current workaround is to
periodically reattempt to delete the old index files.

Peter

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message