[
https://issues.apache.org/jira/browse/OAK-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15022031#comment-15022031
]
Ian Boston commented on OAK-3654:
---------------------------------
Clock.Fast has a maximum resolution of 1ms and when getTime is called it makes
a call to System.nanoTime() and a call to System.getCurrentTimeMillis(), hence
when ACCURATE.getTime() is called it will generally be slower than just calling
System.nanoTime(). The result from Clock.Fast.getTime() is of little use in
the Metrics use case.
Reading the background I think the requirements from Oak for Clock.Fast are
different from the requirements from a Metrics use case. A metrics use case
must have nano second time resolution and should not require more than 1 call
to System.nanoTime() to achieve that. IIUC Oak needed ms time resolution. I
don't believe there is any requirement to deal with long term drift in time (ie
1% or less) over a period of > 10s. If the OS/JDK really is very slow for
System.nanoTime() calls then it's probably a JDK bug. I see the testes were
done on JDK 7u45 which is very old compared to the current release. If there is
a issue with non linearity in time or steps in time then its likely the OS ntpd
is misconfigured.
If you read https://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks
it explains why System.getCurrentTimeMillis() is faster than System.nanoTime()
(measured at 13ns vs 18ns). It also explains why the 2 drift, and strongly
recommends using System.nanoTime() to measure intervals, as that call generally
binds to a crystal oscillator with sub 1% drift. The blog post also warns about
mixing the 2 sources of time. There are some notes specific to the Windows impl
where System.getCurrentTimeMillis() has a 10ms resolution for certain versions
for the JDK.
So in answer to your question: Metrics has considerable production experience.
I would avoid making fundamental changes unilaterally. If there is a real
problem with the Metrics code and how they measure time, I would open an issue
on their bug tracker to validate the issue is real.
> 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)
