jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Klimetschek <aklim...@day.com>
Subject Re: jackrabbit configuration in clustered environment
Date Fri, 06 Nov 2009 14:22:35 GMT
On Fri, Nov 6, 2009 at 13:22, Medha C Sutaria <msutaria@csc.com> wrote:
> Medha - we use BundleFsPersistenceManager.

Note that the FS-based persistence managers don't guarantee any consistency.

See http://wiki.apache.org/jackrabbit/PersistenceManagerFAQ

>> - FileSystem (element in repository.xml) is not important anymore,
>> does not influence peformance
> Is it this tag you are talking about? If yes, then isn't this which decides
> if we want to store data in DB or on LocalFileSystem?
> <FileSystem class="org.apache.jackrabbit.core.fs.local.LocalFileSystem">
>         <param name="path" value="${rep.home}/repository" />
> </FileSystem>

No, it doesn't. As I mentioned, it is legacy and not important. Where
your data is stored depends on the persistence manager (central
persistence component), datastore (if used, either db or file) and
also search index (file only if enabled) and the clustering journal.

> Will adding this tag in our repository.xml make the repository usable with
> SAN? (our repository.xml attached)
> <DataStore class="org.apache.jackrabbit.core.data.FileDataStore">
>         <param name="path" value="${rep.home}/repository/datastore"/>
>         <param name="minRecordLength" value="1000"/>
> </DataStore>

The datastore only stores large binaries. If you want to share your
repository, you need clustering anyway.

See http://wiki.apache.org/jackrabbit/DataStore and

>> See here http://wiki.apache.org/jackrabbit/BackupAndMigration for
>> some options.
> I checked out these options in the past. I've learned that there's a problem
> in migrating versions. That part of the repository tree is secured and
> cannot be exported to an xml file. We needed migration of data when we tried
> to use DbFileSystem instead of LocalFileSystem. I guess we don't need to
> migrate in case of changing other configuration? Eg. using datastore?

Have you tried the (fairly new, since 1.6) RepositoryCopier mentioned
at the end of that wiki page?


> Can you suggest which is the best configuration for clustering (based on
> performance and large repositories)

See the mentioned wiki pages. A database with good and fast clustering
is important. For fast write and streaming of large binaries a shared
filedatastore is optimal, though that depends on the speed of the SAN.


Alexander Klimetschek

View raw message