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:30:24 GMT
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.

Carsten Ziegeler

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