jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Kiehl <ki...@subshell.com>
Subject Re: Jackrabbits own FileSystem and unit tests
Date Thu, 31 Aug 2006 09:35:38 GMT
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?


View raw message