RE: jackrabbit-oak build #2431: Still Failing
Failed tests: testVersioning(org.apache.jackrabbit.test.api.observation.GetUserDataTest): no events returned the test succeeded in the previous build. I created OAK-1107 and will investigate. Regards Marcel > -Original Message- > From: Travis CI [mailto:ju...@apache.org] > Sent: Dienstag, 22. Oktober 2013 23:46 > To: oak-dev@jackrabbit.apache.org > Subject: jackrabbit-oak build #2431: Still Failing > > Build Update for apache/jackrabbit-oak > - > > Build: #2431 > Status: Still Failing > > Duration: 1329 seconds > Commit: 2bd7b1443cbb93043493b44a1f99a0f43b6888d8 (trunk) > Author: Tobias Bocanegra > Message: OAK-527 Implement Permission evaluation > > - calculate number of permission entries in commit hook > > git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1534792 > 13f79535-47bb-0310-9956-ffa450edef68 > > View the changeset: https://github.com/apache/jackrabbit- > oak/compare/461d4fdc6986...2bd7b1443cbb > > View the full build log and details: https://travis-ci.org/apache/jackrabbit- > oak/builds/12901993 > > -- > sent by Jukka's Travis notification gateway
RE: jackrabbit-oak build #2430: Still Failing
> Too many unapproved licenses: 1 deepTree_everyone.xml does not have a license header. should be fixed now. I added the file to the exlude list. regards marcel > -Original Message- > From: Travis CI [mailto:ju...@apache.org] > Sent: Dienstag, 22. Oktober 2013 19:52 > To: oak-dev@jackrabbit.apache.org > Subject: jackrabbit-oak build #2430: Still Failing > > Build Update for apache/jackrabbit-oak > - > > Build: #2430 > Status: Still Failing > > Duration: 1841 seconds > Commit: 461d4fdc6986688069eac4d93fa80c09e004a637 (trunk) > Author: Angela Schreiber > Message: OAK-527: benchmark tests > > git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1534706 > 13f79535-47bb-0310-9956-ffa450edef68 > > View the changeset: https://github.com/apache/jackrabbit- > oak/compare/5b0260a4ca87...461d4fdc6986 > > View the full build log and details: https://travis-ci.org/apache/jackrabbit- > oak/builds/12890709 > > -- > sent by Jukka's Travis notification gateway
jackrabbit-oak build #2431: Still Failing
Build Update for apache/jackrabbit-oak - Build: #2431 Status: Still Failing Duration: 1329 seconds Commit: 2bd7b1443cbb93043493b44a1f99a0f43b6888d8 (trunk) Author: Tobias Bocanegra Message: OAK-527 Implement Permission evaluation - calculate number of permission entries in commit hook git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1534792 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/461d4fdc6986...2bd7b1443cbb View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/12901993 -- sent by Jukka's Travis notification gateway
Re: Improving the benchmark suite
On Tue, Oct 22, 2013 at 11:39 AM, Jukka Zitting wrote: > Hi, > > On Tue, Oct 22, 2013 at 1:34 PM, Tobias Bocanegra wrote: >> WDYT? > > Any improvements are of course welcome. > > On the other hand I believe we are reaching the limits of what the > benchmark suite was originally designed for, i.e. a quick and simple > mechanism for running basic micro-benchmarks. While it's possible to > incrementally extend the design, I'm afraid that without a clear > roadmap or target architecture we'll end up with an overly complex > solution that'll get increasingly difficult to use and that nobody > outside our core team understands. Instead it might be worth it to > revisit existing generic benchmarking tools like JMeter or JUnitPerf > that I looked at earlier but considered overkill at the time. true :-) > > BR, > > Jukka Zitting
Re: Improving the benchmark suite
Hi, On Tue, Oct 22, 2013 at 1:34 PM, Tobias Bocanegra wrote: > WDYT? Any improvements are of course welcome. On the other hand I believe we are reaching the limits of what the benchmark suite was originally designed for, i.e. a quick and simple mechanism for running basic micro-benchmarks. While it's possible to incrementally extend the design, I'm afraid that without a clear roadmap or target architecture we'll end up with an overly complex solution that'll get increasingly difficult to use and that nobody outside our core team understands. Instead it might be worth it to revisit existing generic benchmarking tools like JMeter or JUnitPerf that I looked at earlier but considered overkill at the time. BR, Jukka Zitting
jackrabbit-oak build #2430: Still Failing
Build Update for apache/jackrabbit-oak - Build: #2430 Status: Still Failing Duration: 1841 seconds Commit: 461d4fdc6986688069eac4d93fa80c09e004a637 (trunk) Author: Angela Schreiber Message: OAK-527: benchmark tests git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1534706 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/5b0260a4ca87...461d4fdc6986 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/12890709 -- sent by Jukka's Travis notification gateway
Improving the benchmark suite
Hi, I'd like to make the following changes to the way how the benchmarks work: 1. add support for executing several benchmarks within the same suite. currently each benchmark has it's own 'setUp()' code that might be expensive to execute. e.g. import a large structure, create nodes, etc. 2. move the concurrency control into the 'suite' as well. so that we can execute the same tests with different concurrency levels. like above, this helps with tests that are expensive to set up. WDYT? Regards, Toby
Re: Oak JCR Observation scalability aspects and concerns
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 wrote: > Hi, > > On Tue, Oct 22, 2013 at 10:39 AM, Carsten Ziegeler > 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 >
RE: jackrabbit-oak build #2429: Broken
hmm, I didn't see this when I ran the TCK tests on my machine, but the test sequence is different on my windows machine. I will disable mongodb again if this is a reoccurring issue... regards marcel > -Original Message- > From: Alex Parvulescu [mailto:alex.parvule...@gmail.com] > Sent: Dienstag, 22. Oktober 2013 16:51 > To: oak-dev@jackrabbit.apache.org > Subject: Re: jackrabbit-oak build #2429: Broken > > Failed tests: > testVersioning(org.apache.jackrabbit.test.api.observation.GetUserDataTest) > : > no events returned > > > On Tue, Oct 22, 2013 at 4:48 PM, Travis CI wrote: > > > Build Update for apache/jackrabbit-oak > > - > > > > Build: #2429 > > Status: Broken > > > > Duration: 1269 seconds > > Commit: 5b0260a4ca87418e0630a816b21b3cdeeb8eec15 (trunk) > > Author: Marcel Reutegger > > Message: Re-enable MongoDB for tests > > > > git-svn-id: > https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@153464213f79535- > 47bb-0310-9956-ffa450edef68 > > > > View the changeset: > > https://github.com/apache/jackrabbit- > oak/compare/ae19429cd3db...5b0260a4ca87 > > > > View the full build log and details: > > https://travis-ci.org/apache/jackrabbit-oak/builds/12882477 > > > > -- > > sent by Jukka's Travis notification gateway > >
Re: Oak JCR Observation scalability aspects and concerns
Hi, On Tue, Oct 22, 2013 at 10:39 AM, Carsten Ziegeler 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
Re: jackrabbit-oak build #2429: Broken
Failed tests: testVersioning(org.apache.jackrabbit.test.api.observation.GetUserDataTest): no events returned On Tue, Oct 22, 2013 at 4:48 PM, Travis CI wrote: > Build Update for apache/jackrabbit-oak > - > > Build: #2429 > Status: Broken > > Duration: 1269 seconds > Commit: 5b0260a4ca87418e0630a816b21b3cdeeb8eec15 (trunk) > Author: Marcel Reutegger > Message: Re-enable MongoDB for tests > > git-svn-id: > https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@153464213f79535-47bb-0310-9956-ffa450edef68 > > View the changeset: > https://github.com/apache/jackrabbit-oak/compare/ae19429cd3db...5b0260a4ca87 > > View the full build log and details: > https://travis-ci.org/apache/jackrabbit-oak/builds/12882477 > > -- > sent by Jukka's Travis notification gateway >
Re: Oak JCR Observation scalability aspects and concerns
Again: can we please have sling debates on dev@sling ? Thanks Felix Von meinem iPad gesendet > Am 22.10.2013 um 16:39 schrieb "Carsten Ziegeler" : > > 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üß > >> +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 >> 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 >>> cziege...@apache.org > > > > -- > Carsten Ziegeler > cziege...@apache.org
Re: Oak JCR Observation scalability aspects and concerns
Hi, >I really would like to have a constructive discussion here. Sure. If we want a fully scalable solution, Sling needs to be changed. > 1. we leave everything as is > 2. we maintain the API as-is in Sling and try to make the implementation >as fast as possible This will limit scalability so I think it's not an option. Making things as fast as possible will only help a little bit, but doesn't solve the problem. Therefore, I wouldn't invest too much time trying to do that. > 4. same as 3. but keep the old Sling API with a bold marker when it's >used that this does not scale Sure, this is what is needed. We also need to change the Jackrabbit API to support listening for local events. As I already wrote, the current mechanism using the "isExternal()" flag doesn't scale. I think we should add a marker interface "LocalObservationListener" or similar. Regards, Thomas
jackrabbit-oak build #2429: Broken
Build Update for apache/jackrabbit-oak - Build: #2429 Status: Broken Duration: 1269 seconds Commit: 5b0260a4ca87418e0630a816b21b3cdeeb8eec15 (trunk) Author: Marcel Reutegger Message: Re-enable MongoDB for tests git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1534642 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/ae19429cd3db...5b0260a4ca87 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/12882477 -- sent by Jukka's Travis notification gateway
Re: Oak JCR Observation scalability aspects and concerns
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üß > +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 >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 > > cziege...@apache.org > > > -- Carsten Ziegeler cziege...@apache.org
Re: Oak JCR Observation scalability aspects and concerns
+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 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 > cziege...@apache.org >
Re: Oak JCR Observation scalability aspects and concerns
On Tue, Oct 22, 2013 at 4:30 PM, Carsten Ziegeler wrote: > ...4. same as 3. but keep the old Sling API with a bold marker when it's used > that this does not scale... That's my favorite choice - along with providing a way for users of those Sling events to specify more precisely what they actually need, so that they can improve the situation over time. -Bertrand
Re: Oak JCR Observation scalability aspects and concerns
Hi :) Speaking as developer using the Sling eventing I just wanted to add that in most cases there are restrictions on Paths (most times not just one but multiple "searchpaths") and on a resourceType (not just exact match but a set or pattern to identify a set of resourceTypes) and in some occasions further constraints like existance or a specific value of a specific property. Currently it is up to the user to do this check within the EventListener, but I think it would be feasible to register a listener that defines those checks that can be processed by the implementation at a low level. But it would be good to ask around in the sling community how these events are used in production to be sure not to miss essential patterns. Cheers Dominik On Tue, Oct 22, 2013 at 4:20 PM, Jukka Zitting wrote: > Hi, > > On Tue, Oct 22, 2013 at 9:59 AM, Felix Meschberger > wrote: > > That's one Event object per event -- not one event per listener per > event. > > This is completely different to JCR. > > You're mistaking the problem here, it's not the number of listeners, > it's the number of events *per listener*. > > What we're looking at here is scaling out to write loads that could > well have over a million changed items per second. On my laptop just > instantiating a dummy Event object takes a few hundred nanoseconds, so > there's no way to process millions of them per second in a single > listener. > > BR, > > Jukka Zitting >
Re: Oak JCR Observation scalability aspects and concerns
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 cziege...@apache.org
Re: Oak JCR Observation scalability aspects and concerns
On Tue, Oct 22, 2013 at 4:19 PM, Thomas Mueller wrote: >>This is the contract we have to maintain in Sling. > Well, we can't maintain this contract, because it blocks scalability I tend to agree, and OTOH not everybody will need the kind of scalability that we're discussing here. Many of the usage patterns described at [1] can be solved without observation, in more scalable ways. Providing a way for users who actually need high scalability to move away from the "catch all events" patterns, using Jukka's whiteboard suggestion for example, sounds good to me. That might require work from such users, but at some point we have to admit that there's no magic. -Bertrand [1] https://cwiki.apache.org/confluence/display/SLING/Observation+usage+patterns#
Re: Oak JCR Observation scalability aspects and concerns
Hi, On Tue, Oct 22, 2013 at 9:59 AM, Felix Meschberger wrote: > That's one Event object per event -- not one event per listener per event. > This is completely different to JCR. You're mistaking the problem here, it's not the number of listeners, it's the number of events *per listener*. What we're looking at here is scaling out to write loads that could well have over a million changed items per second. On my laptop just instantiating a dummy Event object takes a few hundred nanoseconds, so there's no way to process millions of them per second in a single listener. BR, Jukka Zitting
Re: Oak JCR Observation scalability aspects and concerns
Hi, >This is the contract we have to maintain in Sling. Well, we can't maintain this contract, because it blocks scalability. Regards, Thomas
Re: Oak JCR Observation scalability aspects and concerns
Hi, >That's one Event object per event -- not one event per listener per >event. This is completely different to JCR. Well, this still doesn't scale, if every cluster node needs all events. It doesn't matter how many observation listeners you have. To block scalability, it's enough to have one observation listener per cluster node that listens to all events in the whole cluster. Regards, Thomas
Re: Oak JCR Observation scalability aspects and concerns
Hi, On Tue, Oct 22, 2013 at 9:43 AM, Carsten Ziegeler wrote: > This is the contract we have to maintain in Sling. I repeat from my earlier post: > Right, it just means that a deployment with such an observer will have > a built-in scalability limit as at some point the listener will no > longer be able to keep up with all concurrent writes across a large > and busy cluster. > > For now I'd document this limitation and possibly deprecate the > JcrResourceListener functionality. A deployment can turn the > functionality off once it reaches the scalability limit and has > identified/fixed all affected code. In addition to the earlier ideas I listed, the proposed ContentChangeListener is one way we could use to reduce the reliance of application code on the current JcrResourceListener contract, and thus make it easier for a deployment to eventually break through that inherent scalability limit. BR, Jukka Zitting
Re: Oak JCR Observation scalability aspects and concerns
Hi Am 22.10.2013 um 15:52 schrieb Jukka Zitting: > Hi, > > On Tue, Oct 22, 2013 at 9:41 AM, Felix Meschberger wrote: >> The JcrResourceListener just gets JCR Observation events, creates the OSGi >> Event objects >> and hands them over for distribution by the OSGi EventAdmin service. The >> latter service is >> then responsible for dispatching taking the EventHandler service >> registration properties into >> account for filtering. > > Right, but the problem here is that this design can't scale out to > millions of events per second, as it requires each individual OSGi > Event to be instantiated before filtering. The proposed service > interface doesn't need to do that, so it can achieve a much higher > throughput, and since no event queue is needed, there's no need to > worry about the queue filling up. That's one Event object per event -- not one event per listener per event. This is completely different to JCR. Regards Felix > > BR, > > Jukka Zitting smime.p7s Description: S/MIME cryptographic signature
Re: Oak JCR Observation scalability aspects and concerns
Hi, On Tue, Oct 22, 2013 at 9:41 AM, Felix Meschberger wrote: > The JcrResourceListener just gets JCR Observation events, creates the OSGi > Event objects > and hands them over for distribution by the OSGi EventAdmin service. The > latter service is > then responsible for dispatching taking the EventHandler service registration > properties into > account for filtering. Right, but the problem here is that this design can't scale out to millions of events per second, as it requires each individual OSGi Event to be instantiated before filtering. The proposed service interface doesn't need to do that, so it can achieve a much higher throughput, and since no event queue is needed, there's no need to worry about the queue filling up. BR, Jukka Zitting
Re: Oak JCR Observation scalability aspects and concerns
Sling's jcr listener provides an API/contract - so this is an
infrastructure component used by application code (or other infrastructure
code). And as the listener is delegating the promotion of events to the
EventAdmin, the jcr listener does not know if there are event listeners at
all or what kind of events they are interested in. And most OSGI event
listeners listen for all modification events and do their own filtering.
The event send out by the listener contains additional information like the
resource type, that's why the listener is reading every created / changed
node.
This is the contract we have to maintain in Sling.
Carsten
2013/10/22 Jukka Zitting
> Hi,
>
> On Tue, Oct 22, 2013 at 5:21 AM, Felix Meschberger
> wrote:
> > Am 22.10.2013 um 11:17 schrieb Chetan Mehrotra:
> >> I think in Sling case it would make sense for it to be implemented as
> >> an Observer. And I had a look at implementation of some of the
> >> listener implementations of [1] and I think they can be easily moved
> >> to Sling OSGi events
> >
> > To be discussed on the Sling list -- though wearing my Sling hat I am
> > extremely weary of implementing an Oak-dependency in Sling.
> > Sling uses JCR.
>
> Yet Sling is actively looking to expand its support for other non-JCR
> backends. ;-)
>
> I think we should do the same thing here, i.e. have an
> implementation-independent abstraction in Sling that can be
> implemented both by plain JCR and directly by Oak.
>
> As discussed, the main scalability problem with the current
> JcrResourceListener design is that it needs to handle *all* changes
> and the event producer has no way to know which events really are
> needed. To avoid that problem and to make life easier for most typical
> listeners, I would suggest adding a whiteboard service interface like
> the following:
>
> interface ContentChangeListener {
> void contentAdded(String pathToAddedNode);
> void contentChanged(String pathToChangedNode);
> void contentRemoved(String pathToRemovedNode);
> }
>
> By registering such a service with a set of filter properties that
> identify which content changes are of interest, the client will start
> receiving callbacks at these methods whenever such changes are
> detected. The filter properties could be something like this:
>
> paths - the paths under which to listen for changes
> types - the types of nodes of interest
> nodes - the names of nodes of interest
> properties - the names of properties of interest
>
> For example, the following declaration would result in callbacks
> whenever there's a base version change of a versionable README.txt
> node somewhere under /source subtree:
>
> paths = "/source"
> types = "mix:versionable"
> nodes = "README.txt"
> properties = "jcr:baseVersion"
>
> Additionally, a "granularity" property could be set to "coarse" to
> indicate that it's fine to deliver events just at the top of a
> modified subtree. For example, if changes are detected both at /foo
> and /foo/bar, a coarsely grained listener would only need to be
> notified at /foo. Setting the property to "fine" would result in
> callbacks for both /foo and /foo/bar.
>
> For proper access controls, the service would also need to have a
> "credentials" property that contains the access credentials to be used
> for determining which events the listener is entitled to.
>
> It should be fairly straightforward to support such a service
> interface both with plain JCR observers and with an Oak Observer, with
> the latter being potentially orders of magnitude faster.
>
> BR,
>
> Jukka Zitting
>
--
Carsten Ziegeler
cziege...@apache.org
Re: Oak JCR Observation scalability aspects and concerns
Hi
Am 22.10.2013 um 15:27 schrieb Jukka Zitting:
> Hi,
>
> On Tue, Oct 22, 2013 at 5:21 AM, Felix Meschberger wrote:
>> Am 22.10.2013 um 11:17 schrieb Chetan Mehrotra:
>>> I think in Sling case it would make sense for it to be implemented as
>>> an Observer. And I had a look at implementation of some of the
>>> listener implementations of [1] and I think they can be easily moved
>>> to Sling OSGi events
>>
>> To be discussed on the Sling list -- though wearing my Sling hat I am
>> extremely weary of implementing an Oak-dependency in Sling.
>> Sling uses JCR.
>
> Yet Sling is actively looking to expand its support for other non-JCR
> backends. ;-)
That bears an interesting question, though: What is the relationship of Oak to
JCR ?
>
> I think we should do the same thing here, i.e. have an
> implementation-independent abstraction in Sling that can be
> implemented both by plain JCR and directly by Oak.
>
> As discussed, the main scalability problem with the current
> JcrResourceListener design is that it needs to handle *all* changes
> and the event producer has no way to know which events really are
> needed. To avoid that problem and to make life easier for most typical
> listeners, I would suggest adding a whiteboard service interface like
> the following:
What you are describing is already implemented in the JcrResourceListener and
the OSGi EventAdmin service ;-)
The JcrResourceListener just gets JCR Observation events, creates the OSGi
Event objects and hands them over for distribution by the OSGi EventAdmin
service. The latter service is then responsible for dispatching taking the
EventHandler service registration properties into account for filtering.
Events are collated on a node level with names of added, removed, and modified
properties listed in event properties and the node path provided by the path
property. Plus we add an indication of whether the event occurred locally or on
another cluster node as well as the event's user id if available.
Adding more properties to filter on would certainly be possible.
Regards
Felix
>
>interface ContentChangeListener {
>void contentAdded(String pathToAddedNode);
>void contentChanged(String pathToChangedNode);
>void contentRemoved(String pathToRemovedNode);
>}
>
> By registering such a service with a set of filter properties that
> identify which content changes are of interest, the client will start
> receiving callbacks at these methods whenever such changes are
> detected. The filter properties could be something like this:
>
>paths - the paths under which to listen for changes
>types - the types of nodes of interest
>nodes - the names of nodes of interest
>properties - the names of properties of interest
>
> For example, the following declaration would result in callbacks
> whenever there's a base version change of a versionable README.txt
> node somewhere under /source subtree:
>
>paths = "/source"
>types = "mix:versionable"
>nodes = "README.txt"
>properties = "jcr:baseVersion"
>
> Additionally, a "granularity" property could be set to "coarse" to
> indicate that it's fine to deliver events just at the top of a
> modified subtree. For example, if changes are detected both at /foo
> and /foo/bar, a coarsely grained listener would only need to be
> notified at /foo. Setting the property to "fine" would result in
> callbacks for both /foo and /foo/bar.
>
> For proper access controls, the service would also need to have a
> "credentials" property that contains the access credentials to be used
> for determining which events the listener is entitled to.
>
> It should be fairly straightforward to support such a service
> interface both with plain JCR observers and with an Oak Observer, with
> the latter being potentially orders of magnitude faster.
>
> BR,
>
> Jukka Zitting
smime.p7s
Description: S/MIME cryptographic signature
Re: Oak JCR Observation scalability aspects and concerns
Hi,
On Tue, Oct 22, 2013 at 5:21 AM, Felix Meschberger wrote:
> Am 22.10.2013 um 11:17 schrieb Chetan Mehrotra:
>> I think in Sling case it would make sense for it to be implemented as
>> an Observer. And I had a look at implementation of some of the
>> listener implementations of [1] and I think they can be easily moved
>> to Sling OSGi events
>
> To be discussed on the Sling list -- though wearing my Sling hat I am
> extremely weary of implementing an Oak-dependency in Sling.
> Sling uses JCR.
Yet Sling is actively looking to expand its support for other non-JCR
backends. ;-)
I think we should do the same thing here, i.e. have an
implementation-independent abstraction in Sling that can be
implemented both by plain JCR and directly by Oak.
As discussed, the main scalability problem with the current
JcrResourceListener design is that it needs to handle *all* changes
and the event producer has no way to know which events really are
needed. To avoid that problem and to make life easier for most typical
listeners, I would suggest adding a whiteboard service interface like
the following:
interface ContentChangeListener {
void contentAdded(String pathToAddedNode);
void contentChanged(String pathToChangedNode);
void contentRemoved(String pathToRemovedNode);
}
By registering such a service with a set of filter properties that
identify which content changes are of interest, the client will start
receiving callbacks at these methods whenever such changes are
detected. The filter properties could be something like this:
paths - the paths under which to listen for changes
types - the types of nodes of interest
nodes - the names of nodes of interest
properties - the names of properties of interest
For example, the following declaration would result in callbacks
whenever there's a base version change of a versionable README.txt
node somewhere under /source subtree:
paths = "/source"
types = "mix:versionable"
nodes = "README.txt"
properties = "jcr:baseVersion"
Additionally, a "granularity" property could be set to "coarse" to
indicate that it's fine to deliver events just at the top of a
modified subtree. For example, if changes are detected both at /foo
and /foo/bar, a coarsely grained listener would only need to be
notified at /foo. Setting the property to "fine" would result in
callbacks for both /foo and /foo/bar.
For proper access controls, the service would also need to have a
"credentials" property that contains the access credentials to be used
for determining which events the listener is entitled to.
It should be fairly straightforward to support such a service
interface both with plain JCR observers and with an Oak Observer, with
the latter being potentially orders of magnitude faster.
BR,
Jukka Zitting
Re: Enable MongoDB on travis-ci again
Hi, On Tue, Oct 22, 2013 at 4:08 AM, Marcel Reutegger wrote: > Any objections? None, +1! BR, Jukka Zitting
Re: Oak JCR Observation scalability aspects and concerns
hi felix from what i see Sling heavily relies on jackrabbit-core functionality... i would be very pleased if it would just rely on public API such as JCR, Jackrabbit API and in the future OAK; it doesn't and this is causing a lot of troubles. kind regards angela On 10/22/13 11:21 AM, "Felix Meschberger" wrote: >Hi > >Am 22.10.2013 um 11:17 schrieb Chetan Mehrotra: > >> On Mon, Oct 21, 2013 at 11:39 PM, Jukka Zitting >> wrote: >>> 3) The Observer mechanism allows a listener to look at repository >>> changes in variable granularity and frequency depending on application >>> needs and current repository load. Thus an Oak Observer can >>> potentially process orders of magnitude more changes than a JCR event >>> listener that needs to look at each individual changed item. >> >> +1 >> >> I think in Sling case it would make sense for it to be implemented as >> an Observer. And I had a look at implementation of some of the >> listener implementations of [1] and I think they can be easily moved >> to Sling OSGi events > >To be discussed on the Sling list -- though wearing my Sling hat I am >extremely weary of implementing an Oak-dependency in Sling. Sling uses >JCR. > >Regards >Felix > >> >> Chetan Mehrotra >> [1] >>https://gist.github.com/chetanmeh/7081328/raw/listeners-list-filtered.txt >
Re: Oak JCR Observation scalability aspects and concerns
Hi Am 22.10.2013 um 11:17 schrieb Chetan Mehrotra: > On Mon, Oct 21, 2013 at 11:39 PM, Jukka Zitting > wrote: >> 3) The Observer mechanism allows a listener to look at repository >> changes in variable granularity and frequency depending on application >> needs and current repository load. Thus an Oak Observer can >> potentially process orders of magnitude more changes than a JCR event >> listener that needs to look at each individual changed item. > > +1 > > I think in Sling case it would make sense for it to be implemented as > an Observer. And I had a look at implementation of some of the > listener implementations of [1] and I think they can be easily moved > to Sling OSGi events To be discussed on the Sling list -- though wearing my Sling hat I am extremely weary of implementing an Oak-dependency in Sling. Sling uses JCR. Regards Felix > > Chetan Mehrotra > [1] https://gist.github.com/chetanmeh/7081328/raw/listeners-list-filtered.txt smime.p7s Description: S/MIME cryptographic signature
Re: Oak JCR Observation scalability aspects and concerns
On Mon, Oct 21, 2013 at 11:39 PM, Jukka Zitting wrote: > 3) The Observer mechanism allows a listener to look at repository > changes in variable granularity and frequency depending on application > needs and current repository load. Thus an Oak Observer can > potentially process orders of magnitude more changes than a JCR event > listener that needs to look at each individual changed item. +1 I think in Sling case it would make sense for it to be implemented as an Observer. And I had a look at implementation of some of the listener implementations of [1] and I think they can be easily moved to Sling OSGi events Chetan Mehrotra [1] https://gist.github.com/chetanmeh/7081328/raw/listeners-list-filtered.txt
Re: Oak JCR Observation scalability aspects and concerns
On Mon, Oct 21, 2013 at 6:47 PM, Jukka Zitting wrote: > -1 This introduces the problem where a single JCR event listener can > block or slow down all other listeners. That can be mitigated upto an extent by using some sort of Black List (OAK-1084). However current approach of each listener pulling in the diff at its own pace is more robust to handle such cases. > I'm not convinced by the assumption here that the observation > listeners put undue pressure on the underlying MK or its caching. Do > we have some data to prove this point? My reasoning is that if in any > case we have a single (potentially multiplexed as suggested) listener > that wants to read all the changed nodes, then those nodes will still > need to be accessed from the MK and placed in the cache. If another > listener does the same thing, they'll most likely find the items in > the cache and not repeat the MK accesses. The end result is that the > main performance cost goes to the first listener and any additional > ones will come mostly for free, thus the claimed performance benefit > of multiplexing observers is IMHO questionable. > Agreed (and also mentioned earlier) that current approach does cause multiple calls to MK as in most cases the NodeState would be found in the cache. However due the access pattern i.e. same node state being fetched multiple times such entries in cache would get higher priority and occupy memory which would otherwise would have been used to cache NodeState for *latest* revision. This is just an observation and I currently do not have any numbers which indicate that this would cause significant performance issue and further such things are hard to measure. Chetan Mehrotra
jackrabbit-oak build #2425: Fixed
Build Update for apache/jackrabbit-oak - Build: #2425 Status: Fixed Duration: 1559 seconds Commit: c9710c3482c997cdf49e6903e781273e75f9 (trunk) Author: Thomas Mueller Message: OAK-825 Unnecessary performance overhead (too many child nodes are traversed; partially undo) git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1534539 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/7bca7b45a1b7...c9710c348299 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/12868383 -- sent by Jukka's Travis notification gateway
Re: Detecting move operations in node state diffs
On 21.10.13 8:23 , Michael Dürig wrote: IIRC, in JR2 a moved node triggers 3 events: node added, node deleted and node moved. but maybe I'm wrong, but I thought we kept this for backward compatibility. Thanks for the heads up. Will double check. This would in fact simplify event generation in the observation code. Double checked and yes, this is the case: Jackrabbit sends 3 events per move: NODE_ADDED, NODE_REMOVED and NODE_MOVED. Michael
Enable MongoDB on travis-ci again
Hi, I'd like to enable MongoDB again for our builds on travis-ci. We disabled it a while back because time it took to run the TCK tests on MongoMK was too high. The time to run the tests has been reduced quite a lot and our build (with integration tests) should run well within the travis-ci build timeout [0] even with MongoDB enabled. Any objections? Regards Marcel [0] http://about.travis-ci.org/docs/user/build-configuration/#Build-Timeouts
Re: Detecting move operations in node state diffs
Hi, >IIRC, in JR2 a moved node triggers 3 events: node added, node deleted >and node moved. Cool, I didn't know this :-) Regards, Thomas
Re: Oak JCR Observation scalability aspects and concerns
Hi,
I think it's quite clear that "global" observation listeners are not
scalable. (Observation listeners that listen for all events below root,
from all cluster nodes.) It is needed for backward compatibility, but we
need to find a solution to make this obsolete. It's not enough to just
reduce the number of such "global" observation listeners: *all* such
observation listeners have to go away. If we don't do that, then we can't
provide a scalable solution. If the customer adds such an global
observation listener, then OK it's his problem. But if our product (Sling,
CQ) requires such an observation listener, then this is our problem and we
need to solve it.
The only option I see is ensuring *each* observation listener only
receives a subset of the events. That filtering could be:
- Only events that were generated from the current cluster node, for
example by implementing a marker interface ("LocalObservationListener").
Jackrabbit 2.x doesn't support such a marker interface yet. Could the
Sling listener (that listens on "/") do this?
- Only events in a specific path (not "/", and probably not "/content" if
this is where most nodes are).
- Only events of a given node type: it would be tricky to make this
scalable within Oak (observation might need to use the node type index).
Are there other ways to filter events?
Regards,
Thomas
