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 Wed, 30 Aug 2006 15:42:38 GMT
Stefan Guggisberg wrote:

>> There are already working solutions for 2. and 3. So, as you wrote, 
>> the right
>> way would be to refactor jackrabbits core to use an own storage. This 
>> could even
>> be the current FileSystem, while this FileSystem lacks a proper locking
>> mechanism which probably could be added.
> locking is imo not required in the jr FileSystem abstraction since jr 
> (or the
> relevant subcomponent) *owns* the file system.

With locking I meant the ".lock" file jr creates on startup 
(RepositoryImpl.acquireRepositoryLock). This file is created using java.io and 
java.nio. If we could abstract this functionality into FileSystem there would be 
no need for jr to access the filesystem directly to create a ".lock" file.

>> Would that work? The mentioned persistence managers could still use an 
>> own
>> instance of the Jackrabbit FileSystem, while they might be better off 
>> to use the
>> file system directly. I mean there is no sense in telling an XML 
>> persistence
>> manager to use memory or database based FileSystem. You could as well 
>> exchange
>> the persistence manager for a memory or database persistence manager.
> i disagree. you might e.g. want to use the XMLPersistenceManager on a
> DbPersistenceManager.

You probably mean "on a Db_FileSystem_", don't you? I still don't think it's a 
good idea to do this, because you probably won't get a good performance using 
this constellation. But if someone really needs it ...

> there are imo 3 issues which make it currently impossible to run jr
> exclusively in memory, i.e. without leaving any traces on the disk:
> 1. there's obviously an issue with the InMemPersistenceManager;
>   it uses a LocalFileSystem to persist blob's even with 'persistent=false'
>   feel free to open a jira issue for this.

Ok, I will open a ticket.

> 2. lucene doesn't use the jr FileSystem abstraction (there are valid 
> reasons
>    for this and they were explained on the mailing list).
>    you seem to have found a workaround for this. another option could 
> perhaps
>    be to disable SearchIIndex entirely.

But which component should do the queries? Or would you implement a QueryHandler 
which simply traverse all nodes to get query results (performance?)? For me 
using a lucene RAMDirectory is okay. I already added a parameter "persistent" to 
SearchIndex which creates a PersistentIndex based on a RAMDirectory if set to 
"true". I would be glad to provide a patch.

> 3. there's currently no InMemFileSystem available in jr. since you wrote 
> one
>    we'd be very interested if you'd consider contributing it ;-)

I implemented a very simple one based on a Map just to get something working. 
But I would be happy to contribute it if there is demand.

> with the above 3 issues resolved it should imo be possible to run 
> jackrabbit
> entirely in memory.

If I do a search for java.io.File in jackrabbit core I found it to be used e.g. in:


I think these occurrences have to be eleminated as well to make jackrabbit run 
entirely in memory. Am I wrong?


View raw message