jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Darton" <pet...@intrinsica.co.uk>
Subject RE: Scalability/Clustering
Date Tue, 04 Apr 2006 15:40:56 GMT
> Yes, I'm aware of Magnolia, but I'm not yet familiar with it.

Ok, as far as Jackrabiit is concerned, each "instance" of Magnolia
contains four Jackrabbit repositories (it uses them for different
things, only one of them contains the main user content).
A single installation of Magnolia consists of at least two instances of
Magnolia - one "private" and one or more "public" instances.

There's a "private" Magnolia instance (with 4 repositories), and this
were people do all their editing of the data content.  Once they are
happy with what they've written, they hit the big button "publish".
Pressing "publish" causes Magnolia to log in to each "public" instance
in turn and upload the new data.  If someone changes a username/password
on a "public" server without matching that change to the private server,
everything breaks.

This results in scalable read-performance as you can just keep throwing
more servers at the problem, each of which has all the data it needs on
its local disk, and use standard tomcat / web clustering to distribute
the load.
The downside is that write-performance is slow, clunky and (last time I
looked) failed silently.

The other issue is that Magnolia doesn't support any other method of JCR
usage other than embedding the 4 repositories within itself - Magnolia
uses unauthenticated access to its repositories, hence you can't afford
to open up access outside the WebApp without compromising security - no
JCR-RMI etc.

> IIUC this means that the private server has to be accessed 
> explicitely to execute write operations?


> Is there an automatic failover mechanism, i.e. if the private 
> server goes down, a backup private server could take over 
> this responsibility (incl. session failover)?

I don't believe so.
Magnolia seems to have been designed with website publishing in mind,
hence an inability to edit data until IT staff fix an issue isn't a big
deal (whereas the inability of the general public to view the corporate
website would be a big deal).

> OK, thanks for this hint as well. But our customer 
> explicitely prefers a complete open source solution.

I can understand that.
I believe it's always useful to have a "just pour money at it" solution
in reserve in case a more clever solution fails to meet expectations.
Of course, that's only viable if your income from whatever you're doing
scales with performance demand.  Once things take off, and after you've
bought yourself a huge mansion and a ferrari from your profits, paying
for a commercial JCR should be pocket coinage :-)
Until then, we'll all have to try to squeeze as much performance out of
Jackrabbit as we can.

This e-mail has been scanned for viruses by Verizon Business Internet Managed Scanning Services
- powered by MessageLabs. For further information visit http://www.mci.com

View raw message