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 14:37:01 GMT
+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
>

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