You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Chetan Mehrotra (JIRA)" <ji...@apache.org> on 2015/04/12 16:53:12 UTC

[jira] [Commented] (OAK-2596) more (jmx) instrumentation for observation queue

    [ https://issues.apache.org/jira/browse/OAK-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14491501#comment-14491501 ] 

Chetan Mehrotra commented on OAK-2596:
--------------------------------------

Opened OAK-2596 for that

> 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
>            Priority: Blocker
>              Labels: monitoring, observation
>             Fix For: 1.1.8
>
>
> 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)