jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Kernel stats question.
Date Mon, 04 Mar 2013 07:43:03 GMT
Hi,

On Fri, Mar 1, 2013 at 9:42 AM, Ian Boston <ieb@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

Mime
View raw message