[
https://jira.codehaus.org/browse/MNG-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358232#comment-358232
]
Michael Osipov edited comment on MNG-5626 at 11/29/14 4:45 AM:
---------------------------------------------------------------
Christian,
I am currently patching the source code and noticed some issues which out of
our control. At [some
points|https://github.com/eclipse/aether-core/search?p=1&q=currenttimemillis&utf8=%E2%9C%93]
in Eclipse Aether {{System.currentTimeMillis}} is used for start times or
durations. That needs to be changed to nanotime and scaled down to
milliseconds. Please file an issues with Aether and link to this one.
Having a look at our code and the JavaDoc of {{nanoTime}} it does not look that
simple because {{nanoTime}} is *not* related to the wall clock at all, it is
arbitrary. It would be completely wrong to convert from {{nanoTime}} to
{{currentTimeMillis}}.
Read [this|http://stackoverflow.com/a/1776053/696632] SO answer by a Google
employee.
was (Author: michael-o):
Christian,
I am currently patching the source code and noticed some issues which out of
our control. At [some
points|https://github.com/eclipse/aether-core/search?p=1&q=currenttimemillis&utf8=%E2%9C%93]
in Eclipse Aether {{System.currentTimeMillis}} is used for start times or
durations. That needs to be changed to nanotime and scaled down to
milliseconds. Please file an issues with Aether and link to this one. I will
continue with our changes.
> Avoid negative durations or handle them correctly
> -------------------------------------------------
>
> Key: MNG-5626
> URL: https://jira.codehaus.org/browse/MNG-5626
> Project: Maven
> Issue Type: Bug
> Components: Logging
> Affects Versions: 3.2.1
> Reporter: Christian Jung
> Assignee: Michael Osipov
> Priority: Minor
>
> In issue MNG-5623 we reported an exception when printing the reactor summary
> if one of the times was negative.
> I saw in one case, that the overall maven build time, as measured from
> outside (i.e. by our QuickBuild system) was -10.8 seconds. The corresponding
> reactor summary was:
> {code}
> 13:55:25,184 INFO - Reactor Summary:
> 13:55:25,184 INFO -
> 13:55:25,184 INFO - module1 ...........................................
> SUCCESS [ 5.911 s]
> 13:55:25,184 INFO - module2 ...........................................
> SUCCESS [ 0.255 s]
> 13:55:25,184 INFO - gpPlaygroundBase-lnx-x64-gcc4 .....................
> SUCCESS [-27.-64 s]
> 13:55:25,185 INFO -
> ------------------------------------------------------------------------
> 13:55:25,185 INFO - BUILD SUCCESS
> 13:55:25,185 INFO -
> ------------------------------------------------------------------------
> 13:55:25,185 INFO - Total time: -20.-73 s
> 13:55:25,185 INFO - Finished at: 2014-04-28T13:55:25+01:00
> 13:55:25,572 INFO - Final Memory: 32M/439M
> 13:55:25,572 INFO -
> ------------------------------------------------------------------------
> {code}
> The thing is quite hard to reproduce, the machines were virtual machines that
> have been running for quite a long time.
> Our administrators suspected that just at this point, the local clock was
> synchronized with some outer source.
> We should check if such negative durations can be avoided, and if not, they
> should be handled correctly.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
