jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rakesh Vidyadharan <rak...@sptci.com>
Subject Re: organizations using Jackrabbit in production environment
Date Tue, 15 Mar 2011 10:12:23 GMT

On 15 Mar 2011, at 03:19, Michael Wechner wrote:

> On 3/15/11 12:19 AM, Rakesh Vidyadharan wrote:
>> On 14 Mar 2011, at 15:10, kazim_ssuet@yahoo.com wrote:
>>> Hi,
>>> Are there any organizations/companies that use jackrabbit as their
>>> production content management system? Can somebody name a few? and how many
>>> files might there be in their system?
>>> And which approach is better db blob storage or file system storage and what
>>> are the pros/cons of each?
>>> Thanks,
>>> KS.
>> http://press.uchicago.edu/ - Built using Magnolia 4.4.2 which uses JackRabbit 1.6.4
as the data store.
>> We are using the file system blob store.  The blob store tends to create a ton of
directories which makes file system backup/restore quite slow.
> Did you consider introducing a "fail over environment"? We had similar problems, but
by "mirroring" the data (and application) we don't have the problem of a slow restore in the
first place, but rather just switch the environment (and then do the restore for the system
which was previously the master). Hence the backup
> is only for the worst case if the master and mirror should be down for whatever reasons.
> Cheers
> Michael

Yes.  In fact Magnolia uses distinct author and public instances concept (with the ability
to run multiple public instances per author instance).  In our case, we have one author and
two public instances, which means our data is always replicated across three servers.  However,
we still need to maintain backup processes in case of catastrophic failures, and the recovery
process is only for such a case.

That said, the existence of mirrors does not remove the issue with so many directories and
files. Simple archiving and unarchiving (once in a while we need to do that to update our
development and qa instances) tend to take much longer than they should because of this issue.
 It is not a deal breaker, but it could have been better.

View raw message