jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Runde, Kevin" <kru...@NameProtect.com>
Subject RE: Help using JCR-RMI
Date Fri, 28 Apr 2006 19:19:48 GMT
Thanks for the reply!!!

The backup part worries me a lot. In general do exports always not
include version data? Sorry I haven't had a chance to play with
Versioning yet. Are there any plans or JSR to address this. Maybe I am
in the wrong here, but as I see it a CMS is really a form of database
and as with any database to be used in an enterprise  system you need
the ability to do online back ups. Now for my home projects that's not
an issue. Jackrabbit is awesome and really great to work with and I'd
love to use it more at work, but this prevents that.

Server Mode:
It turns out our problem getting the RMI server to run correctly was a
stupid user error. My RMI expert didn't know you could specify 2 jars in
the codebase when you start the RMI server. After you confirmed it
should work as easily as I thought it should I pushed him some more and
he figured it out.

Thank you!
Kevin Runde

-----Original Message-----
From: Jukka Zitting [mailto:jukka.zitting@gmail.com] 
Sent: Thursday, April 27, 2006 1:37 PM
To: users@jackrabbit.apache.org
Subject: Re: Help using JCR-RMI


On 4/27/06, Runde, Kevin <krunde@nameprotect.com> wrote:
> 1) Backup: Is it possible to do an "online backup" of a repository and
> if so how could this be done.

The cleanest way is to use a system view XML export of your content.
With binary properties included this will give you a complete content
snapshot that you can easily copy or restore. The drawbacks of this
approach are that the XML export can easily get pretty large, and that
the export won't contain any version histories or custom nodetypes
(you can't import the jcr:system tree even though it can be exported).

> 2) Server Mode: I've seen the JCR-RMI package and tried to get a
> server running, but keep running into issues. Has anyone gotten an RMI
> server running in Java 1.5? If so could you share with me your Daemon
> class and the startup options used when you run the Daemon. I saw a
> HOWTO 0.2 in the mail archives, but that hasn't helped solve my

What sort of issues are you facing? The essential code I'm using is
shown below:

    Repository repository = ...; // The local repository
    String name = ...; // The RMI URL for the repository

    RemoteAdapterFactory factory = new ServerAdapterFactory();
    RemoteRepository remote = factory.getRemoteRepository(repository);
    Naming.bind(name, remote);  // Make the RMI binding using

For a more complete example with a number of extra features see the
registerRMI() method of the RepositoryStartupServlet class in the
jcr-server webapp:

> 3) What are these RMI speed issues I see mentioned? Again I searched
> mail list, but didn't find any thing about it.

The main performance issues with JCR-RMI are related to the very
fine-grained remote access policy it uses. By design JCR-RMI uses
little or no caching or clustering of data, so almost all JCR method
calls using JCR-RMI cause network roundtrips. For example  no
properties of a retrieved node are cached client-side. Instead all
Node.getProperty() and even Property.getValue() calls are performed
over the network. Another issue is that all JCR object instances
(Nodes, Properties, etc.) are backed by JCR-RMI using a separate
Remote object. These constraints are there on purpose, as the main
design goal of JCR-RMI has been to be as transparent and
straightforward RMI mapping of the JCR API as reasonable.

JCR-RMI is actually surprisingly fast given these design constraints,
and I have no immediate plans to make major performance changes (there
are a few minor streamlining issues remaining). One of the goals of
JSR 283 is to come up with a way to make remote JCR easier and faster,
so I'm holding back any major plans until the first public JSR 283
drafts are out.

As a summary I'd say that JCR-RMI gives good enough performance for an
editor or administrator client, but you generally wouldn't want to use
it to back a web site or another heavily accessed frontend unless you
use aggressive caching. A good solution for many deployments would be
to have Jackrabbit deployed on the same container as the main
application that uses it, and to use JCR-RMI to access the repository
from other applications that don't run inside the same container.


Jukka Zitting

Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development

View raw message