Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (asf.osuosl.org: domain of gcaj-jackrabbit-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@jackrabbit.apache.org
From: Christoph Kiehl <kiehl@subshell.com>
Subject: Re: Jackrabbits own FileSystem and unit tests
Date: Thu, 31 Aug 2006 11:35:38 +0200
Lines: 45
Message-ID: <ed6al2$6sh$1@sea.gmane.org>
References: <ecnbqh$g75$1@sea.gmane.org>
	 <510143ac0608270703h78e4863bm8a2040aca36455c4@mail.gmail.com>
	 <ecvd82$oa5$1@sea.gmane.org>
	 <90a8d1c00608300308w73ff275cp987296f40f3fe924@mail.gmail.com>
	 <ed4bn5$7c6$1@sea.gmane.org>
 <90a8d1c00608300910h72d77267uf1813bcc2e91f2b0@mail.gmail.com>
 <ed4ei6$jn0$1@sea.gmane.org> <44F6888B.7070202@gmx.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
In-Reply-To: <44F6888B.7070202@gmx.net>
Sender: news <news@sea.gmane.org>

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