Hi, On Fri, Mar 1, 2013 at 9:42 AM, Ian Boston <i...@tfd.co.uk> wrote: > I am more interested in counters than average or last operation time > measurements as that gives and idea of where hotspots, multi threaded > throughput at full load and anomalies rather than general slowness. > (not saying time measurements are not useful, just hard to interpret > in a highly multi threaded server under load)
Good point. It would be good to use OAK-364 to gather ideas for numbers that would be useful or at least interesting to track. > Does that mean observers get a stream revision tokens, and its up to > them to queue the revision for later processing, even if that means > just keeping the last one worked on and the most recent (ie no queue > at all, just a range of revisions) ? That depends on the level at which you're observing the repository. At the lowest level you can just poll the repository for new revisions of the content tree and do a content diff to find out what changed. The repository itself does nothing special for you, just gives you access to the latest revision and the ability to compare two revisions of the repository. Since explicitly managing such a polling mechanism can be a bit cumbersome, we also provide a way to register listeners (see the o.a.j.oak.spi.commit.Observer interface) that get notified when there are new revisions in the repository, like you describe above. The thread that makes these contentChanged() callbacks is controlled by the repository, so the observers should avoid too expensive calculations. Finally at the JCR level we have the JCR observation listeners that receive a stream of event objects instead of repository revisions. Again the repository is in charge of making the callbacks and thus the observer should be mindful of the amount of time it takes. > Will the Kernel blacklist slow observers, as the OSGi event manager does? Currently it doesn't, but for the latter two cases we'll probably need something like that. The first case is essentially decoupled from the underlying repository, so there's no need for the repository to worry about such observers. (Of course they could still consume a lot of CPU and IO, bu that would then be a higher level deployment concern and would only indirectly affect the repository.) BR, Jukka Zitting
