[ https://issues.apache.org/jira/browse/OAK-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15021081#comment-15021081 ]
Chetan Mehrotra commented on OAK-3654: -------------------------------------- {quote} The Timer.update(...) isn't very clean compared to the other patterns that leave performing the timing operation to the implementation. Perhaps consider exposing a wrapper for Context in the TimerStats interface. {quote} Ack and that would come next. For the first cut I wanted to reduce the amount of refactoring required bq. nanoTimer and performance. I have measured the overhead of the metrics library to be about 10% timing calls of about 1E-7s. Good to know then that overhead is not appreciable. > Integrate with Metrics for various stats collection > ---------------------------------------------------- > > Key: OAK-3654 > URL: https://issues.apache.org/jira/browse/OAK-3654 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: core > Reporter: Chetan Mehrotra > Assignee: Chetan Mehrotra > Fix For: 1.4 > > Attachments: OAK-3654-v1.patch, query-stats.png > > > As suggested by [~ianeboston] in OAK-3478 current approach of collecting > TimeSeries data is not easily consumable by other monitoring systems. Also > just extracting the last moment data and exposing it in simple form would not > be useful. > Instead of that we should look into using Metrics library [1] for collecting > metrics. To avoid having dependency on Metrics API all over in Oak we can > come up with minimal interfaces which can be used in Oak and then provide an > implementation backed by Metric. > This task is meant to explore that aspect and come up with proposed changes > to see if its feasible to make this change > * metrics-core ~100KB in size with no dependency > * ASL Licensee > [1] http://metrics.dropwizard.io -- This message was sent by Atlassian JIRA (v6.3.4#6332)