jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominik Süß <dominik.su...@gmail.com>
Subject Re: Oak JCR Observation scalability aspects and concerns
Date Tue, 22 Oct 2013 15:13:46 GMT
I just opened a thread at sling-dev for further discussion about api and
implementation changes on sling side [0]

For discussions around usage of this api within sling please use this
linked thread [0].

Best regards
Dominik


[0] markmail.org/thread/plb7ledhsna33r3g


On Tue, Oct 22, 2013 at 4:54 PM, Jukka Zitting <jukka.zitting@gmail.com>wrote:

> Hi,
>
> 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
> scratch.
>
> 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.
>
> BR,
>
> Jukka Zitting
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message