Classes

Java's i/o APIs not used directly, but rather all i/o is through this API. This permits things such as:

• implementation of RAM-based indices;
• implementation indices stored in a database, via JDBC;
• implementation of an index as a single file;

Files with the specified extensions are placed in the primary directory; others are placed in the secondary directory. The provided Set must not change once passed to this class, and must allow multiple threads to call contains at once.

NOTE: this API is new and experimental and is subject to suddenly change in the next release.

Typical use might look like:

            new Lock.With(directory.makeLock("my.lock")) {
            public Object doBody() {
            ... code to execute while locked ...
            }
            }.run();
            

Base class for Locking implementation. {@link Directory} uses instances of this class to implement locking.

Note that there are some useful tools to verify that your LockFactory is working correctly: {@link VerifyingLockFactory}, {@link LockStressTest}, {@link LockVerifyServer}.

NOTE: memory mapping uses up a portion of the virtual memory address space in your process equal to the size of the file being mapped. Before using this class, be sure your have plenty of virtual address space, e.g. by using a 64 bit JRE, or a 32 bit JRE with indexes that are guaranteed to fit within the address space. On 32 bit platforms also consult {@link #setMaxChunkSize} if you have problems with mmap failing because of fragmented address space. If you get an OutOfMemoryException, it is recommened to reduce the chunk size, until it works.

Due to this bug in Sun's JRE, MMapDirectory's {@link IndexInput#close} is unable to close the underlying OS file handle. Only when GC finally collects the underlying objects, which could be quite some time later, will the file handle be closed.

This will consume additional transient disk usage: on Windows, attempts to delete or overwrite the files will result in an exception; on other platforms, which typically have a "delete on last close" semantics, while such operations will succeed, the bytes are still consuming space on disk. For many applications this limitation is not a problem (e.g. if you have plenty of disk space, and you don't rely on overwriting files on Windows) but it's still an important limitation to be aware of.

This class supplies the workaround mentioned in the bug report (disabled by default, see {@link #setUseUnmap}), which may fail on non-Sun JVMs. It forcefully unmaps the buffer on close by using an undocumented internal cleanup functionality. {@link #UNMAP_SUPPORTED} is

CopyC#

true

Implements {@link LockFactory} using native OS file locks. Note that because this LockFactory relies on java.nio.* APIs for locking, any problems with those APIs will cause locking to fail. Specifically, on certain NFS environments the java.nio.* locks will fail (the lock can incorrectly be double acquired) whereas {@link SimpleFSLockFactory} worked perfectly in those same environments. For NFS based access to an index, it's recommended that you try {@link SimpleFSLockFactory} first and work around the one limitation that a lock file could be left when the JVM exits abnormally.

The primary benefit of {@link NativeFSLockFactory} is that lock files will be properly removed (by the OS) if the JVM has an abnormal exit.

Note that, unlike {@link SimpleFSLockFactory}, the existence of leftover lock files in the filesystem on exiting the JVM is fine because the OS will free the locks held against these files even though the files still remain.

If you suspect that this or any other LockFactory is not working properly in your environment, you can easily test it by using {@link VerifyingLockFactory}, {@link LockVerifyServer} and {@link LockStressTest}.

Implements {@link LockFactory} using {@link File#createNewFile()}.

NOTE: the javadocs for

CopyC#

File.createNewFile

When this happens, a {@link LockObtainFailedException} is hit when trying to create a writer, in which case you need to explicitly clear the lock file first. You can either manually remove the file, or use the {@link org.apache.lucene.index.IndexReader#unlock(Directory)} API. But, first be certain that no writer is in fact writing to the index otherwise you can easily corrupt your index.

If you suspect that this or any other LockFactory is not working properly in your environment, you can easily test it by using {@link VerifyingLockFactory}, {@link LockVerifyServer} and {@link LockStressTest}.