Using FileMode.MEMORY_MAPPED leaves the file locked, even after closing the reader

[ikalatch]

When using FileMode.MEMORY_MAPPED, the .mmdb file on the file system is not available for manipulation (renaming, moving, deleting) even after the reader is closed.

Using FileMode.MEMORY doesn't suffer from this problem. See sample unit test below. Could be OS-related (using JDK7 on Win7, MaxMindDB: v.0.3.0, GeoIP2: v.0.6.0).
Ran into the issue while working on automatically updating the .mmdb file once a month in a long-running process.

import java.io.File;
import java.io.IOException;
import org.junit.Assert;
import org.junit.Test;
import com.maxmind.db.Reader.FileMode;
import com.maxmind.geoip2.DatabaseReader;
import com.maxmind.geoip2.DatabaseReader.Builder;

public class _GeolocationFileUpdate
{
    private static final String GEO_LITE2_CITY_MMDB = "GeoLite2-City.mmdb";
    private static final String GEO_LITE2_CITY2_MMDB = "GeoLite2-City2.mmdb";
    private static final String DIR = "c://Temp/"; //adjust if on a diff. OS. Place the .mmdb file here
    private static final File f1 = new File( DIR + GEO_LITE2_CITY_MMDB );
    private static final File f2 = new File( DIR + GEO_LITE2_CITY2_MMDB );

    @Test
    public void testSwitchingMem()
    {
        try
        {
            // make sure the file name is reverted after renaming:
            f2.renameTo( f1 );

            Builder builder = new DatabaseReader.Builder( f1 );
            builder.fileMode( FileMode.MEMORY );
            DatabaseReader reader = builder.build();
            reader.close();

            // make sure file is not in use by a process:
            Assert.assertTrue( f1.renameTo( f2 ) );
        }
        catch ( IOException e )  {  e.printStackTrace();  }
    }

    @Test
    public void testSwitchingMemMapped()
    {
        try
        {
            // make sure the file name is reverted after renaming:
            f2.renameTo( f1 );

            Builder builder = new DatabaseReader.Builder( f1 );
            builder.fileMode( FileMode.MEMORY_MAPPED );
            DatabaseReader reader = builder.build();
            reader.close();

            // make sure file is not in use by a process:
            // ! test fails on the line bellow, file is in use !:
            Assert.assertTrue( f1.renameTo( f2 ) );
        }
        catch ( IOException e ) { e.printStackTrace(); }
    }
}

[ikalatch]

After some more research - seems like the culprit is the com.maxmind.db.ThreadBuffer class. In the case of FileMode.MEMORY_MAPPED it establishes a MappedByteBuffer through the map() method on the FileChannel and once a memory buffer is mapped to a file this way there is no way to unmap. Only when the MappedByteBuffer is garbage collected or the JVM shuts down is the file lock released...
From the Java docs of the map() method: "A mapping, once established, is not dependent upon the file channel that was used to create it. Closing the channel, in particular, has no effect upon the validity of the mapping. Many of the details of memory-mapped files are inherently dependent upon the underlying operating system and are therefore unspecified. The behavior of this method when the requested region is not completely contained within this channel's file is unspecified. Whether changes made to the content or size of the underlying file, by this program or another, are propagated to the buffer is unspecified. The rate at which changes to the buffer are propagated to the file is unspecified.
For most operating systems, mapping a file into memory is more expensive than reading or writing a few tens of kilobytes of data via the usual read and write methods. From the standpoint of performance it is generally only worth mapping relatively large files into memory".

[oschwald]

Thanks for the report and looking into this further. I have seen this issue on Linux systems, but I suspect that your theory about the cause is correct

Is your application multithreaded and are you using the reader from multiple threads?

[ikalatch]

Yep, the app is multi-threaded and a single instance of the reader is being used across all threads - as recommended in the GeoIp docs.

[oschwald]

I spent a bit of time looking into this issue, and, from what I can tell, there isn't really a way to change the behavior. The lock will only be removed when the Reader, TheadBuffer, and subsequently MappedByteBuffer are garbage collected.

[ikalatch]

Agreed. The implementation of the ThreadBuffer in MEMORY_MAPPED mode needs to be overhauled for the file lock to be releasable (but then it won't be memory mapped).

Ideally there should be a third mode besides MEMORY and MEMORY_MAPPED that uses plain 'read's and avoids the drawbacks of both MEMORY (reserves too much memory) and MEMORY_MAPPED (locks the file) at the (probable) cost of speed...

[oschwald]

During development, we had a non-mmap file mode. It ended up being about 1/10 to 1/6 as fast as the memory mapped mode. It also required a completely different code path from the two other modes as you can't access the file as a byte buffer.

[oschwald]

I added a note about this to the MaxMind DB Reader documentation. I am going to close this issue given that it isn't actionable, but please feel free to open an issue about a file mode on the MaxMind DB Reader repo.

[ikalatch]

Sounds good. I see in the note that it is Windows only - does it work for you (releases the file lock) on Linux?BTW, on the notes page - https://github.com/maxmind/MaxMind-DB-Reader-java - the links to 'specification' and 'Perl writer' lead both to 404 s.

[oschwald]

Thanks for catching those links. We moved the repos around. I'll fix that.

Yeah, the file locking is a bit different on Linux and it doesn't lead to the same sort of issues.

[LukeButters]

It may be of interest to know that https://github.com/xerial/larray have some how managed to support un-mmapping of files without the need for the GC to eventually run.

I have also found that using a random access file (or a file channel directly) is also slow. This can be speed up by adding some simple caching, so long as you are reading small amounts within the same buffered block e.g. you read one byte at a time for bytes that are withing 4096bytes of each other. You have to write your own caching random access file in java though or just use what I wrote.

I think it would be neat if the reader would let us supply our own ByteBuffer or something similar so we could use something like larray and close the mmaped file when required.

[oschwald]

It looks like that package uses JNI to wrap their own C-based memory mapping implementation.