Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Scalable, failsafe and distributed Jackrabbit setup?
From: Lukas Kahwe Smith <mls@pooteeweet.org>
In-Reply-To: <4B1DDAB0-EFB4-4481-8E15-F4D7A6962428@pooteeweet.org>
Date: Mon, 16 May 2011 15:28:05 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A5186AA-A347-46C5-A828-B229A3B5E416@pooteeweet.org>
References: <4CE22B07.4020700@chregu.tv> <4CE2CCC2.1060003@wyona.com>
 <4B1DDAB0-EFB4-4481-8E15-F4D7A6962428@pooteeweet.org>
To: users@jackrabbit.apache.org


On 13.05.2011, at 16:54, Lukas Kahwe Smith wrote:

>=20
> On 16.11.2010, at 19:26, Michael Wechner wrote:
>=20
>> On 11/16/10 6:56 AM, Christian Stocker wrote:
>>> So what do you think? Is my approach feasible? Am I overthinking it =
and
>>> the first approach is by far good enough? I don't say, that I need =
the
>>> full setup yet, I just don't want to get into trouble later, when we
>>> actually would need it and have to refactor a lot.
>>=20
>> I understand your concerns, but as long as your CMF instances are =
using the API
>> consistently you shouldn't have to worry much about refactoring at =
some later stage,
>> whereas this doesn't mean that you don't have to exchange your =
persistence implementation
>> at some later stage and hence I would suggest that you assume from =
the very beginning that you will have
>> to migrate your data from one implementation into another one.
>>=20
>> Re the actual persistence implementation I don't think there is a =
one-fits-all solution,
>> but rather it depends on what kind of data you are dealing with and =
what kind of queries
>> you want to make and as you are pointing out write versus read =
access, whereas with
>> webapps becoming more interactive I think that write access becomes =
much more important
>> than today and hence its important to keep this mind re your setup.
>=20
>=20
> FYI
>=20
> =
http://blog.liip.ch/archive/2011/05/04/how-to-make-jackrabbit-globally-dis=
tributable-fail-safe-and-scalable-in-one-go.html
>=20
> One of the things we are looking to do here is to use this setup to =
have a spare slave with jackrabbit running on some small machine, so =
that in case our data center disappears forcing a rebuild we already =
have a clone able [1] setup ready. One thing we want to ensure is that =
this clone is consistent.=20
>=20
> I have only found docs for CRX on this, but it seems to also work with =
a stock Jackrabbit to do Lucene index checks on startup:
> =
http://dev.day.com/content/kb/home/Crx/CrxSystemAdministration/HowToCheckL=
uceneIndex.html
>=20
> I wonder if there is already some way to trigger these checks on a =
running Jackrabbit?


should have read the CheckIndex docs to the end:
=
http://lucene.apache.org/java/2_4_0/api/org/apache/lucene/index/CheckIndex=
.html

java -ea:org.apache.lucene... org.apache.lucene.index.CheckIndex =
pathToIndex [-fix] [-segment X] [-segment Y]

regards,
Lukas Kahwe Smith
mls@pooteeweet.org