On 1 March 2013 18:19, Jukka Zitting <[email protected]> wrote: > Hi, > > On Thu, Feb 28, 2013 at 11:55 PM, Ian Boston <[email protected]> wrote: >> Are there plans to expose kernel stats from Oak ? > > Yes, see OAK-364 [1]. Though so far we haven't yet implemented > anything along these lines.
Nice thanks. 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) > > One related idea I was already thinking about implementing is exposing > cache statistics [2] from the Guava caches we're using at the > MicroKernel level. > >> The Jackrabbit ObservationDispatcher has a queue that contains a >> AtomicInteger indicating the size of the queue. If Observers are slow >> in responding to asynchronous notifications the queue can grow >> rapidly. > > This actually is an area that won't be an issue with Oak, as instead > of using a centralized queue from where events are pushed to observers > we're allowing each observer to generate events by comparing > successive repository revisions at their own pace. Thus one slow > observer will only block itself. 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) ? Will the Kernel blacklist slow observers, as the OSGi event manager does? Best Regards Ian BTW: part of the reason for asking is I am looking into exposing more stats over in Sling. > > Of course there are other areas where such metrics will still be highly > useful. > > [1] https://issues.apache.org/jira/browse/OAK-364 > [2] http://code.google.com/p/guava-libraries/wiki/CachesExplained#Statistics > > BR, > > Jukka Zitting
