[
https://issues.apache.org/jira/browse/OAK-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14492981#comment-14492981
]
Michael Dürig commented on OAK-2755:
------------------------------------
I didn't realise you are using {{@Reference}} for tracking {{Observer}}
instances. I this case you won't be able to resolve a double dispatch the way I
envisioned. However, tracking {{Observer}} instances is probably not the right
thing to do here. That interface is for observing content changes, not for
monitoring. This also manifests itself in the code of {{ListenerStatsData}}:
{code}
if (observer instanceof BackgroundObserver){
backgroundObserver = (BackgroundObserver) observer;
queueStats = backgroundObserver.getQueueStats();
Observer delegate = ((BackgroundObserver) observer).getDelegate();
if (delegate instanceof ChangeProcessor){
filterProvider = ((ChangeProcessor) delegate).getFilterProvider();
}
}
{code}
All this casting to implementations, why the interfaces and all the nice OSGi
abstractions then in the first place?
IMO a better approach would register an MBean for the {{BackgroundObserver}}
and/or one for the {{ChangeProcessor}}. The {{ConsolidatedListenerMBeanImpl}}
could then just track those without any implementation dependencies. That MBean
might then live in an utility/tooling package or even outside Oak. Such an
approach would thus correctly separate the main concern of the involved classes
from the monitoring concerns.
> Consolidated JMX view of all EventListener related statistics
> -------------------------------------------------------------
>
> Key: OAK-2755
> URL: https://issues.apache.org/jira/browse/OAK-2755
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Labels: monitoring, observation
> Fix For: 1.0.13, 1.3.0
>
> Attachments: OAK-2755-2.patch, OAK-2755.patch,
> consolidated-listener-stats-2.png, consolidated-listener-stats.png
>
>
> Oak Observation support exposes a {{EventListenerMBean}} [1] which provide
> quite a bit of details around registered observation listeners. However in a
> typical application there would be multiple listeners registered. To simplify
> monitoring it would be helpful to have a _consolidated_ view of all listeners
> related statistics.
> Further the stats can also include some more details which are Oak specific
> * Subtree paths to which the listener listens to - By default JCR Api allows
> single path however Oak allows a listener to register to multiple paths
> * If listener is enabled to listen to cluster local and cluster external
> changes
> * Size of queue in BackgroundObserver
> * Distribution of change types present in the queue - Local, External etc
> [1]
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-api/src/main/java/org/apache/jackrabbit/api/jmx/EventListenerMBean.java
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
