jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig (JIRA) <j...@apache.org>
Subject [jira] [Commented] (OAK-2596) more (jmx) instrumentation for observation queue
Date Thu, 12 Mar 2015 11:36:38 GMT

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

Michael Dürig commented on OAK-2596:

The gust of the implementation for this will be in the Jackrabbit code base.

> 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.1.8, 1.0.13
> 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

View raw message