jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: Oak JCR Observation scalability aspects and concerns
Date Tue, 22 Oct 2013 14:49:57 GMT
Again: can we please have sling debates on dev@sling ?


Von meinem iPad gesendet

> Am 22.10.2013 um 16:39 schrieb "Carsten Ziegeler" <cziegeler@apache.org>:
> 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
View raw message