jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Oak JCR Observation scalability aspects and concerns
Date Tue, 22 Oct 2013 14:54:21 GMT

On Tue, Oct 22, 2013 at 10:39 AM, Carsten Ziegeler <cziegeler@apache.org> wrote:
> Just to reiterate :) if we go with 3 or 4, someone has to do the work in
> Sling (and other places) and adapt the code. As obviously as soon as a
> single listener is using the old pattern, the whole mechanism is mood.

I think we can lay the groundwork with tools like the ones outlined in
this thread, and postpone much of the required refactoring work to
when we do have the appropriate benchmarks in place and a use case
where such scale is needed in practice. At that point we can also make
a more reasoned judgement of whether option 2 or 4 is the better
solution for that particular case, i.e. are we still within such scale
that normal optimization is good enough and broader design changes
aren't needed. And we'll also have someone with a bad enough itch to

As for 3 vs. 4, I think option 3 is clearly unworkable, as there's no
immediate need to break backwards compatibility for most normal
deployments. I'd go for option 4 of keeping the current mechanism with
a note detailing the scalability issue and instructions on how to
prepare for avoiding it. Note that option 4 is compatible with 2, as
we can proceed on both fronts concurrently.


Jukka Zitting

View raw message