Does FSDirectory inhibits adoption of MMapDirectory and others?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Does FSDirectory inhibits adoption of MMapDirectory and others?
I see there is a lot of activity on MMapDirectory, NIODirectory etc.
Looking at the implementation of MMapDirectory, it inherits FSDirectory. It
appears to me that FSDirectory is becoming the default interface as opposed
to Directory. The biggest problem with using FSDirectory is that all segments
files are written to a single Directory, putting an artificial requirement
of contiguous disk space for the entire search engine. This is the reason, why
we had to use a custom implementation Directory interface and
 any high end application would be forced to do the same.
 (Does Nutch use FSDirectory?)

Couple of thoughts come to my mind

(a) All new Directories such as MMapDirectory, NIODirectory inside the Lucene
sandbox should implement Directory and not FSDirectory. If we can make
FSDirectory non-final, they can encapsulate FSDirectory. This allows, applications
to extend FSDirectory and garner the benefits of any advance functionality.

(b) Alternatively set some flexibility in FSDirectory.
One thought is to add an interface such as :
  public interface FSLocation {
    public File getFile(String stName);

Ultimately, these changes will help the adoption of the new directories directly
from the Sandbox.


To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]