jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: remove JackrabbitRepository.shutdown()
Date Mon, 28 Apr 2008 15:48:30 GMT

On Mon, Apr 28, 2008 at 3:29 PM, Thomas Müller <thomas.mueller@day.com> wrote:
>  What about the other points? I repeat them here and I hope I get an
>  answer on them as well:

Your other points are good, no concerns about them.

>  >  But how many applications really need to shutdown the repository in
>  >  the generic case?
>  All applications that call shutdown. Felix's sling/jcrapp for example.
>  A backup tool. A test case.

All of your examples are implementation-specific. Is there a generic
JCR application (i.e. one with only a dependency to jcr-1.0.jar plus
potentially also jackrabbit-api), that needs

> As you know, the TransientRepository _should_ shut down the repository
> automatically when the last session is closed.

It's a bug if it doesn't.

> However this doesn't work currently, see bug
> https://issues.apache.org/jira/browse/JCR-1551

The repository is closed at the last logout(). The shutdown delay is
caused by a static instance variable that holds a few threads for an
extended period of time after the shutdown, but that doesn't for
example prevent some other process from opening the repository.

> how come nobody found out?

Probably because most Jackrabbit apps are long-lived, and even if the
application itself is closed (for example a webapp is undeployed) the
JVM is still running so the extra thread doesn't show up.

>  > You need to do that *only* if you embed the
>  >  repository, in which case you already are bound to a single
>  >  implementation.
>  No, you are not bound to a single implementation. If you use Spring or
>  Google Guice or another factory to create the repository, you are not.

Then your configuration is bound to the implementation. More notably,
in such cases it's the IoC container that should be in charge of the
repository lifecycle, and since the repository startup configuration
is Jackrabbit-specific I don't see why the shutdown part needs to be

>  >  IMHO, if we want to make the repository more manageable, I'd opt for a
>  >  JMX MBean.
>  What's the point of adding complexity? Why exactly you like to avoid
>  shutdown in an interface?

I have no concerns about shutdown being in an interface as such, I
just object to putting it in a client-level interface. For example the
idea of a separate RepositoryManager interface that covers both
repository startup and shutdown is IMHO much better.

>  > [JCRLog] It doesn't cover  repository startup.
>  Of course it does. It must cover that aspect, otherwise it wouldn't be
>  useful. Have a look at the JCRLog implementation and the samples.

Sorry, doesn't cover the startup in a repository-independent manner.
Since JCRLog already has a dependency to jackrabbit-core and uses
specific class references (TransientRepository) to start up a
repository, why should it have a generic mechanism for shutting the
repository down?

>  I fail to see in your mail why it is better to _not_ have an
>  interface. Could you please explain why you rather not have this
>  interface please?

Again, no objections against an interface as such. My main point is
that such an interface shouldn't be something that you'd cast a
Repository object to.

Somewhat on the same lines as Toby, how about something like this:

    public interface RepositoryMBean {
        void startRepository() throws RepositoryException;
        void stopRepository() throws RepositoryException;
        boolean isRunning();
        Repository getRepository();

A normal Java application can use this interface to control an
embedded repository (but note that it still needs a dependency to the
implementation class):

    RepositoryMBean bean = new RepositoryMBeanImpl(/* config */);
    try {
    } finally {

Note that there is no need to worry about access control or things
like whether a given repository instance was created by this
management object. If a client has a reference to the management
object, then it has full control over the repository. For example the
doSomething() method in the above example would have no way to
shutdown the repository, even by casting the repository instance to
whatever interface or implementation class.

And since the interface follows the JMX conventions for MBeans, it's
very easy to expose the management interface to generic JMX management
tools like jconsole, or even any SNMP-aware network and server
monitoring tools.


Jukka Zitting

View raw message