System time resolution

[Julian Reschke <ju...@gmx.de>]

On 2014-02-17 16:49, Michael Dürig wrote:
>
>
> On 17.2.14 4:41 , Julian Reschke wrote:
>> On 2014-02-17 16:33, Angela Schreiber wrote:
>>> hm... doesn't fail for me.
>>> as usual: it would be good if you could provide some details if
>>> the problem consistently shows up.
>>> ...
>>
>> What kind of details do you need?
>>
>
> There might be more helpful information in target/unit-tests.log.
>
> Michael

So this problem (or one part of this problem) is caused by the attempt 
to use the creation time of the version as key in a sorted map (trying 
to sort the history, probably for linear version histories).

This can fail on machines that are sufficiently fast and at the same 
time have a > 1ms resolution for systemCurrentTimeMillis (and Date).

In this particular case, the right fix is probably not to attempt to 
sort here at all. If it's needed for linear version histories it can be 
done somewhere higher by following the successor relation.

A general question is whether we should try to improve the precision of 
the JCR time stamps. I believe that calculating them based on naoTime 
might help.

Best regards, Julian

Re: System time resolution

[Felix Meschberger <fm...@adobe.com>]

Hi

Right. If you want to get a historic sequence of events, the time stamp is not the way to do that — have been burnt before and now using counters.

Regards
Felix

Am 19.02.2014 um 09:38 schrieb Julian Reschke <ju...@gmx.de>:

> On 2014-02-19 09:37, Julian Reschke wrote:
>> ...
>> A general question is whether we should try to improve the precision of
>> the JCR time stamps. I believe that calculating them based on naoTime
>> might help.
>> ...
> 
> (I just checked and nanoTime is recommended only for calculating time differences...)
> 
> BR, Julian

Re: System time resolution

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Wed, Feb 19, 2014 at 9:38 AM, Julian Reschke <ju...@gmx.de>
wrote:
> ...(I just checked and nanoTime is recommended only for calculating time
> differences...)

Yes, quoting [1] "This method provides nanosecond precision, but not
necessarily nanosecond resolution (that is, how frequently the value
changes) - no guarantees are made except that the resolution is at least as
good as that of currentTimeMillis()" - so nanoTime is not better
than currentTimeMillis for generating unique values.

-Bertrand

[1]
http://docs.oracle.com/javase/7/docs/api/java/lang/System.html#nanoTime()

Re: System time resolution

[Julian Reschke <ju...@gmx.de>]

On 2014-02-19 09:37, Julian Reschke wrote:
> ...
> A general question is whether we should try to improve the precision of
> the JCR time stamps. I believe that calculating them based on naoTime
> might help.
> ...

(I just checked and nanoTime is recommended only for calculating time 
differences...)

BR, Julian

Re: System time resolution

[Julian Reschke <ju...@gmx.de>]

On 2014-02-19 09:37, Julian Reschke wrote:
> On 2014-02-17 16:49, Michael Dürig wrote:
>>
>>
>> On 17.2.14 4:41 , Julian Reschke wrote:
>>> On 2014-02-17 16:33, Angela Schreiber wrote:
>>>> hm... doesn't fail for me.
>>>> as usual: it would be good if you could provide some details if
>>>> the problem consistently shows up.
>>>> ...
>>>
>>> What kind of details do you need?
>>>
>>
>> There might be more helpful information in target/unit-tests.log.
>>
>> Michael
>
> So this problem (or one part of this problem) is caused by the attempt
> to use the creation time of the version as key in a sorted map (trying
> to sort the history, probably for linear version histories).
>
> This can fail on machines that are sufficiently fast and at the same
> time have a > 1ms resolution for systemCurrentTimeMillis (and Date).
>
> In this particular case, the right fix is probably not to attempt to
> sort here at all. If it's needed for linear version histories it can be
> done somewhere higher by following the successor relation.
> ...

Turns out that simple versioning already uses a different code path...