jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: Jackrabbits own FileSystem and unit tests
Date Wed, 30 Aug 2006 16:10:08 GMT
On 8/30/06, Christoph Kiehl <kiehl@subshell.com> wrote:
> 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

yup, i meant DbFileSystem

> 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:
>
> SessionImpl.createAccessManager()
> RepositoryConfig.init()
> RepositoryConfig.internalCreateWorkspaceConfig()
>
> I think these occurrences have to be eleminated as well to make jackrabbit run
> entirely in memory. Am I wrong?

yes ;-)

re:  SessionImpl.createAccessManager()

jr does have a 'physical' home directory. i don't think that we should change
that. that doesn't necessarily mean that any files are written to that
directory.

the other references to java.io.File are within conditional blocks which are
never executed, depending on your configuration.

cheers
stefan

>
> Cheers,
> Christoph
>
>

Mime
View raw message