Building a Jackrabbit roadmap

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

Hi,

There are a lot of things going on around Jackrabbit, and I'd like to
summarize my thoughts on the some of the efforts in an attempt to
start drafting a Jackrabbit roadmap that would present our views of
what will likely be happening within the next few years. This roadmap
could then be used to create more detailed release plans and to
evaluate progress over time.

I've organized this message around various topics, in no particular
order. Feedback on any or all topics is very much welcome! Please feel
free to start a new thread if you'd like to focus on some particular
issue in more detail.

JSR 283
-------

The JCR 2.0 spec being specified by JSR 283 will be a major source of
new features to be added in Jackrabbit within the next year or so. The
current plan is to target Jackrabbit 2.0 as the JSR 283 reference
implementation, which means that we'll need to have at least some sort
of an implementation of all the new features being introduced by the
updated spec.

I'd like to use the JSR 283 public review draft as the baseline
requirements document for Jackrabbit 2.0. Once the draft is out we
should create feature requests for all the major changes and start
working on an iterative plan to get all the features implemented by
the 2.0 release. If possible, we should introduce some of the new
features already during the 1.x release cycle, perhaps by including
any API changes in jackrabbit-api instead of depending on any
jcr-2.0.jar snapshots.

Documentation
-------------

Documentation is definitely one of the key "features" that need major
improvements in Jackrabbit. To raise awareness of the need for
documentation, I'm planning to start including selected documentation
tasks in future release plans.

It would also be nice to come up with ways to better tap the amount of
knowledge transfer that is happening on the Jackrabbit mailing lists
every day. I'd especially like to make it easier to contribute FAQ
updates and other similar documentation improvements. What should we
do to help people volunteer with these issues?

SPI
---

The SPI effort has been ongoing for a while already, and it would be
good to come up with a clear idea of how and when are we going to
integrate it with the rest of Jackrabbit. The SPI model introduces a
major architectural change, and I'm worried about the adverse effects
that change may have if the integration with the rest of Jackrabbit is
not properly managed.

I'd most like to see the SPI being introduced as an evolutionary step
to jackrabbit-core rather than using just parts of the current core to
build a revolutionary new jackrabbit-spi-backend implementation.

The applicability of the SPI as an intemediate layer within a local
repository implementation as opposed to a network remoting layer has
also not yet been discussed in much detail. Before integrating the SPI
with the rest of the project it would be good to review the design
decisions both to verify that we're not missing anything and (even
more importantly) to better educate the development community of the
details of the SPI model.

Finally, I'm worried about the duplication of effort in the
implementation of transient space, name mapping, and other client-side
features in spi-client and jackrabbit-core. Moving at least parts of
such code to jackrabbit-jcr-commons would be a good idea.

Remote access
-------------

The demand for fast remote JCR access to Jackrabbit repositories will
most likely become more pressing as more people are using Jackrabbit
in various environments. There are some improvements we could make in
JCR-RMI to speed up things, but the basic design of JCR-RMI places
some hard performance limits especially for high-latency connections.

The SPI and the WebDAV work related to it seems like a nice solution
to this issue. Unfortunately this solution still needs more work and
since JCR-RMI already scratches some of the itch away, I'm not sure
when we'll see concrete results. Perhaps this would be a good area for
co-operation with other repository projects?

Clustering
----------

The recent clustering work by Dominique is a great addition to
Jackrabbit, and I'm looking forward to seeing more success and problem
reports from people using the new clustering features.

Architecturally thinking the current clustering design is IMHO not
optimal, as it actually makes the normally "dumb" persistence manager
do the hard work by relying on a shared underlying database. I think
we should eventually find a way to manage all the clustering work
above the persistence layer, but just like with remote access there's
no immediate need for improvements as the current solution covers the
basic needs.

Access control
--------------

A number of people have been writing their own custom AccessManagers
to implement access controls in Jackrabbit repositories. This is a
rather heavy investment for many of the basic access control use cases
that could well be met by a more generic AccessManager implementation.
Contributions in this area would probably be widely appreciated.

Performance
-----------

So far performance and scalability issues have come up every now and
then as isolated incidents or discussions, which to me seems good as
it shows that we don't have any glaring performance problems that
every other user would be tripping over. This however doesn't mean
that we couldn't do better, and I'm quite convinced that as the
growing Jackrabbit install base is sooner or later going ot include
people with very strict performance and scalability requirements that
can't easily be solved by just throwing in more hardware.

To better prepare for solving such issues it would be good for us to
have some standard performance benchmarks in place. They wouldn't need
to be very complex, even something that simply populates a large
workspace and retrieves all the stored content would be a good start
as long as the test is repeatable and produces usable reports.

One very general underlying issue that I see as a major performance
bottleneck in the current Jackrabbit design is the reliance on
sequential operation in many critical areas of the codebase. Perhaps
the most glaring issue is the requirement to synchronize
DatabasePersistenceManager.store() even though the content being
stored is almost embarrassingly parallel. In the age of multicore
processors found even on laptop computers we should be looking at all
opportunities to parallelize the code.

Modularity
----------

Even though Jackrabbit supports a number of extension interfaces, the
basic implementation structure is IMHO still rather monolithic with
lots and lots of interdependencies across packages and individual
classes. I'm not too worried about this from a technical perspective,
but it makes it harder for the community to work on the codebase in
parallel. A more modular internal structure would enable easier
experimentation and customization, and allow us to both cover a wider
array of requirements and to accept contributions of alternative
implementations of specific features.

The downside of increased modularity is the added effort to manage all
the separate components as a coherent whole. The OSGi model provides a
compelling solution to this problem, and thus I'd like to investigate
options for using OSGi as a way to enable more modularity within
Jackrabbit.

Configuration
-------------

Just like with the modularity issue, the current Jackrabbit
configuration mechanism provides a reasonable level of flexibility for
specific features but is somewhat limited in other areas. There are
people with valid requirements that can't be met by the current
configuration model. We can do quite a lot by incrementally extending
the existing configuration mechanism, but I don't think this solution
will work in the long run especially if we opt for increased
modularity. An IoC-like configuration mechanism, introduced perhaps
along with OSGi modularization, could remove the configuration
limitations for good.

Administration
--------------

There aren't yet too many administration tools for Jackrabbit. Most
configuration needs to be done manually, we don't have a released
low-level content browser/editor tool, options for node type
modifications are very restricted, a comprehensive backup/restore
toolset is not available, etc. Luckily there are a number of ongoing
efforts that will eventually help with the various parts of this
topic, and so I'm not too worried about this issue. We just need to
spend some effort to make any administration tools that get
implemented available to the Jackrabbit users as parts of the official
releases.

Deployment
----------

The current Jackrabbit project structrure and the available
documentation is mostly focused on using Jackrabbit as an embedded
model 1 repository. I think it would make sense for us to gradually
raise the "default" deployment level first to model 2 by focusing on
making the jackrabbit-webapp project more prominent, and later on to
model 3 by creating a standalone  Jackrabbit installer. The last part
is obviously conditional on major improvements in remote access.

This increase in the deployment level would help make Jackrabbit more
an "infrastructure" product as outlined by the goals of the JCR
specification, and would also help manageability and configurability
by making the Jackrabbit runtime environments more predictable.

BR,

Jukka Zitting

Re: Building a Jackrabbit roadmap

[David Nuescheler <da...@gmail.com>]

Hi,

I would like to comment on a particular section of Jukka's excellent
summary of the major topics that we need to clarify on the development
roadmap. I would like to apologize for the delay.

> SPI
> ---
> The SPI effort has been ongoing for a while already, and it would be
> good to come up with a clear idea of how and when are we going to
> integrate it with the rest of Jackrabbit. The SPI model introduces a
> major architectural change, and I'm worried about the adverse effects
> that change may have if the integration with the rest of Jackrabbit is
> not properly managed.
> I'd most like to see the SPI being introduced as an evolutionary step
> to jackrabbit-core rather than using just parts of the current core to
> build a revolutionary new jackrabbit-spi-backend implementation.
I agree that in the longer term the SPI introduces an
additional layer that allows someone to implement the SPI
instead of JCR to pass the TCK, which probably is simpler
for any connector or adapter to a legacy repository
but also for someone who wants to implement a brand new
repository from scratch.

I think it is safe to say that we did not primarily focus on a
client/server model [1] when developing Jackrabbit v1.0,
which I think was a good decision at the time.

Nevertheless I think that a remoting beyond the current RMI
implementation more and more becomes a need and the SPI
offers very good direction there as well. Personally, I think
that the RMI implementation that goes through the SPI layer
should already be much faster than the "traditional" JCR RMI
remoting.

> The applicability of the SPI as an intemediate layer within a local
> repository implementation as opposed to a network remoting layer has
> also not yet been discussed in much detail. Before integrating the SPI
> with the rest of the project it would be good to review the design
> decisions both to verify that we're not missing anything and (even
> more importantly) to better educate the development community of the
> details of the SPI model.
Agreed.

I think that the natural step for a review of the applicability of the SPI for
Jackrabbit while conserving the current architecture was to introduce the
SPI over JCR layer that allows to for example use the SPI for remoting
on top of Jackrabbit and on top of other content repositories.

Possibly this will allow everybody to get more exposure and work with
the SPI to make sure that nothing was overlooked, before we drill
deeper in to the core. I very much agree that the Jackrabbit
development community needs to feel comfortable with the SPI before
we discuss an architectural change of that magnitude that I believe the
SPI would introduce.

Comparing timelines with JSR-283, it may well be that a completely
refactored Jackrabbit SPI implementation is not within reach for the final
release of JSR-283.
Nevertheless, I think that the current SPI over JCR implementation already
offers most of the benefits of the SPI, while only introducing a small
performance penalty. So I think we are in good shape for now.

Do you think that makes sense?

regards,
david

[1] http://jackrabbit.apache.org/doc/deploy.html#Model+3:+The+Repository+Server

Re: Building a Jackrabbit roadmap

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

Hi,

On 2/15/07, Angela Schreiber <an...@day.com> wrote:
> when i went through the jsr283 specification in december 06,
> i started with such a listing (a very simply one though) in
> order to get an overview abouth things that need to be added
> or modified both in the SPI layer and in the JCR implementation
> (currently focusing on jcr2spi).
>
> if you want me too, i can provide you that overview. since
> quite some changes were made to jsr283 for the last f2f,
> i might be missing a couple things, but the older stuff
> should more or less complete.

Such a list would be very helpful, thanks!

BR,

Jukka Zitting

Re: Building a Jackrabbit roadmap

[Angela Schreiber <an...@day.com>]

hi jukka

> JSR 283
> -------
> 
> The JCR 2.0 spec being specified by JSR 283 will be a major source of
> new features to be added in Jackrabbit within the next year or so. The
> current plan is to target Jackrabbit 2.0 as the JSR 283 reference
> implementation, which means that we'll need to have at least some sort
> of an implementation of all the new features being introduced by the
> updated spec.
> 
> I'd like to use the JSR 283 public review draft as the baseline
> requirements document for Jackrabbit 2.0. Once the draft is out we
> should create feature requests for all the major changes and start
> working on an iterative plan to get all the features implemented by
> the 2.0 release. If possible, we should introduce some of the new
> features already during the 1.x release cycle, perhaps by including
> any API changes in jackrabbit-api instead of depending on any
> jcr-2.0.jar snapshots.

when i went through the jsr283 specification in december 06,
i started with such a listing (a very simply one though) in
order to get an overview abouth things that need to be added
or modified both in the SPI layer and in the JCR implementation
(currently focusing on jcr2spi).

if you want me too, i can provide you that overview. since
quite some changes were made to jsr283 for the last f2f,
i might be missing a couple things, but the older stuff
should more or less complete.

kind regards
angela

Re: Building a Jackrabbit roadmap

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

Hi,

On 2/15/07, Miro Walker <mi...@gmail.com> wrote:
> On a similar topic, I think addressing JCR-672 and dealing with the
> deadlock problems in Jackrabbit once and for all :-) would be a great
> idea. This has been an ongoing problem for a long time now, but each
> attempt to address it seems to come to the conclusion that the work
> required is a bit too big and scary to do easily. Perhaps if we added
> it to a roadmap for a specific version, then we could bite the bullet
> and take it on?

I generally prefer to use features to drive the release plans rather
than the other way around, but you're right in that this is a serious
problem that needs to be solved rather sooner than later.

One high-level solution that I've been thinking about as a potential
way to both avoid extensive locking and to increase the level of
parallelism is to use multiversion concurrency control. MVCC is
especially attractive since it never blocks read operations, and would
even allow us to get rid of the in-memory transient space. Such a
change would however require massive refactoring of Jackrabbit
internals, so I'd only embark on such a mission if there's wide
consensus that it's actually something we should do. Having a couple
of long-time database experts around would also make me much more
confident of the success with such a change...

> On the topic of performance, one thing that I'd like to get included
> if possible (perhaps this flows from some of the JSR-283 versioning
> changes) is a model of versioning that doesn't duplicate all data
> between workspaces, but rather allows workspaces to store pointers
> into a central version history. This would vastly increase the
> performance of cross-workspace operations, a major headache for us.

Good idea! A related improvement would be to only store deltas of
successive versions in the version store.

BR,

Jukka Zitting

Re: Building a Jackrabbit roadmap

[Miro Walker <mi...@gmail.com>]

Hi Jukka,

> Performance
> -----------
> To better prepare for solving such issues it would be good for us to
> have some standard performance benchmarks in place. They wouldn't need
> to be very complex, even something that simply populates a large
> workspace and retrieves all the stored content would be a good start
> as long as the test is repeatable and produces usable reports.

That sounds like a great idea. The advantage of this is that if people
have specific performance requirements for use cases that are more
complex than the simple write 1 workspace / read 1 workspace, the
tests could be easily extended to support these too.

> One very general underlying issue that I see as a major performance
> bottleneck in the current Jackrabbit design is the reliance on
> sequential operation in many critical areas of the codebase. Perhaps
> the most glaring issue is the requirement to synchronize
> DatabasePersistenceManager.store() even though the content being
> stored is almost embarrassingly parallel. In the age of multicore
> processors found even on laptop computers we should be looking at all
> opportunities to parallelize the code.

On a similar topic, I think addressing JCR-672 and dealing with the
deadlock problems in Jackrabbit once and for all :-) would be a great
idea. This has been an ongoing problem for a long time now, but each
attempt to address it seems to come to the conclusion that the work
required is a bit too big and scary to do easily. Perhaps if we added
it to a roadmap for a specific version, then we could bite the bullet
and take it on?

On the topic of performance, one thing that I'd like to get included
if possible (perhaps this flows from some of the JSR-283 versioning
changes) is a model of versioning that doesn't duplicate all data
between workspaces, but rather allows workspaces to store pointers
into a central version history. This would vastly increase the
performance of cross-workspace operations, a major headache for us.

Miro