Hi Marcel,
as mentioned before the current search index implementation does not
work on the jackrabbit FileSystem abstraction. The reason is lack of
support for random access on the FileSystemResource which is a
performance killer when lucene is running on top of that.
Hm, I think all these folders & files:
>> ./repository
>> ./repository/index
>> ./repository/index/_0
>> ./repository/index/indexes
>> ./repository/index/ns_mappings.properties
>> ./repository/index/redo.log
>> ./version
>> ./version/blobs
>> ./workspaces
>> ./workspaces/default
>> ./workspaces/default/blobs
>> ./workspaces/default/index
>> ./workspaces/default/index/_0
>> ./workspaces/default/index/indexes
>> ./workspaces/default/index/redo.log
>> ./workspaces/default/workspace.xml
>> ./.lock
could be created using jr's FileSystem. The only problem I see is with the
".lock" file. This file requires FileSystem to implement a proper mechanism to
create lock files. But this could be done.
The indexes itself can use whatever they like, e.g. FSDirectory or RAMDirectory.
This way there will be no files left written to the disk if I use a memory based
file system.
in the long term I would like to put the index in the repository itself.
but that means that the repository (at least internally) has to support
random access on its binary resources.
Hm, sounds interesting, but wouldn't this only work with file system based
persistence managers? I mean, I can't imagine how to get an index with decent
performance using a database based persistence manager in the near future? Do
you already have an idea how achieve the needed performance?
Cheers,
Christoph
