Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of marcel.reutegger@gmx.net
 designates 213.165.64.20 as permitted sender)
Message-ID: <48247B7D.7020603@gmx.net>
Date: Fri, 09 May 2008 18:27:41 +0200
From: Marcel Reutegger <marcel.reutegger@gmx.net>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: users@jackrabbit.apache.org
Subject: Re: Can't get an excerpt when using JCR Webdav I/F
References: <AC8633E3B75B45819EF8E4C4BD4DE929@minbar>
 <48244A9C.1020107@gmx.net> <CAE05E78B0CA4E8CA0279A52FC317FD8@minbar>
In-Reply-To: <CAE05E78B0CA4E8CA0279A52FC317FD8@minbar>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Julio Castillo wrote:
> Question in general regarding architectures. I understand that SPI is going
> through its growing pains, but what is the recommended model when I have a
> farm of application servers that want to use Jackrabbit? My thoughts were to
> use JCR Webdav/SPI to access a server running the Jackrabbit service from
> any of the app servers internally.

that's one possible architecture. you may also consider the following:

1) jcr2spi<->spi-rmi<->spi2jcr<->jackrabbit-core
2) jcr-rmi<->jackrabbit-core

1) as well as the webdav/spi stack you mentioned are not yet optimized for 
performance. we are currently in the process of analyzing message complexity of 
spi calls and finding ways how to minimize them.

2) jcr-rmi is quite mature but does not come with sophisticated client-side 
caches. it works well with applications that do not require high performance.

> If this is not yet mature enough, I will have to bundle jackrabbit with each
> app server sharing a single dB repository with the obvious risk of stepping
> on each other.

I assume you are referring to clustering. yes, that's another alternative.

regards
  marcel