Help using JCR-RMI

["Runde, Kevin" <kr...@NameProtect.com>]

Hi All,

I have been using Jackrabbit in several small home projects and like it
a lot. At work we are looking to complete change how our whole
infrastructure works. One of the main things we do are reports. Our
reports are really Hierarchical sets of text, images, and audit data. To
be honest this feels like a perfect use of Jackrabbit. There are a few
issues I need to resolve first:

1) Backup: Is it possible to do an "online backup" of a repository and
if so how could this be done.

2) Server Mode: I've seen the JCR-RMI package and tried to get a simple
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 issues.

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

Thanks,
Kevin Runde

Re: Help using JCR-RMI

[Jukka Zitting <ju...@gmail.com>]

Hi,

On 4/27/06, Runde, Kevin <kr...@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 simple
> 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 issues.

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 java.rmi.Naming

For a more complete example with a number of extra features see the
registerRMI() method of the RepositoryStartupServlet class in the
jcr-server webapp:
http://svn.apache.org/viewcvs.cgi/jackrabbit/trunk/jcr-server/webapp/src/java/org/apache/jackrabbit/j2ee/RepositoryStartupServlet.java?view=markup

> 3) What are these RMI speed issues I see mentioned? Again I searched the
> 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.

BR,

Jukka Zitting

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