jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: Oak JCR Observation scalability aspects and concerns
Date Tue, 22 Oct 2013 14:39:11 GMT
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.

Carsten


2013/10/22 Dominik Süß <dominik.suess@gmail.com>

> +1 on 4 since I fear 3 will create some overhead for existing solutions
> that won't need this kind of scalabilty (and therefore create uncessary
> efforts for migration).  This is the old "compat" pattern seen so often.
>
>  IMHO this should be an extension that "can" be installed but is not
> available by default (to force devs to decide on that but being lazy and
> not care about deprecation).
>
>
> On Tue, Oct 22, 2013 at 4:30 PM, Carsten Ziegeler <cziegeler@apache.org
> >wrote:
>
> > I really would like to have a constructive discussion here. I think the
> > Sling use case is pretty well explained now - that's an api Sling offers
> > and which is used by a lot of code out there (a great part of Sling is
> > based on the OSGi events and layers on top of Sling are using it as
> well).
> > That's a fact and it's also a fact that listeners for the OSGi event
> > usually listener for all events.
> >
> > Now basically we have three/four options:
> > 1. we leave everything as is - it works but might be slow with larger
> > installations and heavy writes
> > 2. we maintain the API as-is in Sling and try to make the implementation
> as
> > fast as possible
> > 3. we break compatibility in Sling, find a better solution, rewrite parts
> > of Sling and require all downstream users to rewrite their stuff
> > well, the fourth option would be
> > 4. same as 3. but keep the old Sling API with a bold marker when it's
> used
> > that this does not scale
> >
> > For the sake of compatibility I really would like to go with 2 which
> might
> > require changes in Sling and Oak but sounds to me as the best compromise.
> > In addition, it really would help the discussion if we would have
> > performance tests showing us the real boundaries in terms of scalability
> > with observation with some real figures.
> >
> > Thanks
> > Carsten
> > --
> > Carsten Ziegeler
> > cziegeler@apache.org
> >
>



-- 
Carsten Ziegeler
cziegeler@apache.org

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