[ https://issues.apache.org/jira/browse/OAK-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14358624#comment-14358624 ]
Michael Dürig commented on OAK-2596: ------------------------------------ Initial implementation at my Github fork: https://github.com/mduerig/jackrabbit-oak/tree/OAK-2596. You need a recent Jackrabbit 2.9-SNAPSHOT build for this. As this depends on the Jackrabbit 2.9.2 release I bump the fix version to 1.1.9 > more (jmx) instrumentation for observation queue > ------------------------------------------------ > > Key: OAK-2596 > URL: https://issues.apache.org/jira/browse/OAK-2596 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core > Affects Versions: 1.0.12 > Reporter: Stefan Egli > Assignee: Michael Dürig > Labels: monitoring, observation > Fix For: 1.0.13, 1.1.9 > > > While debugging issues with the observation queue it would be handy to have > more detailed information available. At the moment you can only see one value > wrt length of the queue: that is the maximum of all queues. It is unclear if > the queue is that long for only one or many listeners. And it is unclear from > that if the listener is slow or the engine that produces the events for the > listener. > So I'd suggest to add the following details - possible exposed via JMX? : > # add queue length details to each of the observation listeners > # have a history of the last, eg 1000 events per listener showing a) how long > the event took to be created/generated and b) how long the listener took to > process. Sometimes averages are not detailed enough so such a in-depth > information might become useful. (Not sure about the feasibility of '1000' > here - maybe that could be configurable though - just putting the idea out > here). > # have some information about whether a listener is currently 'reading events > from the cache' or whether it has to go to eg mongo > # maybe have a 'top 10' listeners that have the largest queue at the moment > to easily allow navigation instead of having to go through all (eg 200) > listeners manually each time. -- This message was sent by Atlassian JIRA (v6.3.4#6332)