On 2015-03-20 10:20, Davide Giannella wrote:
On 20/03/2015 07:36, Julian Reschke wrote:
On 2015-03-20 01:48, Alexander Klimetschek wrote:
AFAIK, this is expected, on Windows (or some Windows versions),
System.currentTimeMillis() only has a resolution of 15ms
http://stackoverflow.com/questions/7859019/system-currenttimemillis-is-not-accurate-on-windows-xp
Cheers,
Alex
That's not really true, see
<http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/201403.mbox/%[email protected]%3E>
- you need to distinguish the clock (which can be as "good" as 1ms,
see above mail), from timers.
Can we do a quick test? Let's put the scheduler to 15ms or 20ms and see
if it still fails for windows. AFAIR the purpose of Clock.FAST was to
have a non-accurate but fast clock.
Note that it doesn't always fail :-)
Anyway, it seems to me that Clock.Fast can't be made to work reliably,
and also that we really don't understand the reason why we don't
simply use Clock.SIMPLE. We currently use Clock.Fast in RepositoryImpl
and StopWatchLogger; we should have a look at these uses, and decide
whether we can switch to Clock.SIMPLE.
I can speak of the StopwatchLogger (SWL) as I coded it. It was meant for
having a common interface for tracking executions timing in logs. It
uses the Clock.FAST as it was meant to be as less impacting performance
as possible and it was not meant to replace a profiler; so an accuracy
of 10ms was ok. You can find a usage example here on my GH fork (0).
For the SWL class I think that an accuracy of 20ms should be ok. (see
above).
(0)
https://github.com/davidegiannella/jackrabbit-oak/blob/OAK-2472/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/async/AsyncEditorProcessor.java#L140
We need to consider two things:
- a clock that is maintained by a timer will not achieve 10ms
granularity on all platforms; the code currently sort-of pretends that
it does
- even if we increase the interval, we'll still have no guarantee that
the clock *does* change within the interval; all that we have is a
promise from Java to try, but it's best effort
As such we need to understand whether both a bigger interval *and* some
additional inaccuracy is ok for all current uses (as in RepositoryImpl,
SessionDelegate etc).
(I'm a bit worried because of the other hard-to-reproduce test failures
on Windows, such as those related to observation and query iterators;
maybe they are caused by the clock not behaving as expected???)
Best regards, Julian
