[
https://jira.codehaus.org/browse/MNG-5623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=345520#comment-345520
]
Christian Jung commented on MNG-5623:
-------------------------------------
[~Michael.Osipov] 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 -
------------------------------------------------------------------------
13:55:25,619 INFO - Executing post-execute action...
{code}
Note that this did not crash because the string uses only 9 characters. It had,
if the 1000s had been printed correctly as -27.-064
Our administrators suspected that just at this point, the local clock was
synchronized with some outer source.
After reading [this stackoverflow
article|http://stackoverflow.com/questions/2978598/will-sytem-currenttimemillis-always-return-a-value-previous-calls]
i doubt that we can ever be sure that all durations are positive, even if we
used {{nanoTime()}} instead of {{getCurrentTimeMillis()}}.
> Exception when printing Reactor Summary
> ---------------------------------------
>
> Key: MNG-5623
> URL: https://jira.codehaus.org/browse/MNG-5623
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Logging
> Affects Versions: 3.2.1
> Reporter: Christian Jung
> Assignee: Michael Osipov
> Attachments: MNG-5626.patch
>
>
> We get the following exception in maven 3.2.1:
> {code}
> 17:14:29,313 INFO - org.emftext.commons.antlr3_4_0 ....................
> SUCCESS [ 13.624 s]
> 17:14:29,313 INFO - acceleo-maven .....................................
> SUCCESS [ 0.811 s]
> 17:14:29,313 INFO - com.ptvgroup.geoplatform.dfspec ...................
> SUCCESS [ 6.208 s]
> 17:14:29,313 INFO - com.ptvgroup.geoplatform.dfspec.resource.dfspec ...
> SUCCESS [ 9.181 s]
> 17:14:29,313 INFO - com.ptvgroup.geoplatform.dfspec.generator .........
> SUCCESS [ 27.518 s]
> 17:14:29,313 INFO - df7-java-generator ................................
> SUCCESS [ 12.459 s]
> 17:14:29,313 INFO - df7-cpp-generator .................................
> SUCCESS [ 16.046 s]
> 17:14:29,313 INFO - df7-wiki-generator ................................
> SUCCESS [ 8.318 s]
> 17:14:29,313 INFO - dfutils ...........................................
> SUCCESS [ 17.114 s]
> 17:14:29,313 INFO - com.ptvgroup.geoplatform.dfspec.resource.dfspec.ui
> SUCCESS [ 7.206 s]
> 17:14:29,313 INFO - com.ptvgroup.geoplatform.dfspec.validation ........
> SUCCESS [ 10.988 s]
> 17:14:29,313 INFO - df7-cpp-testgenerator .............................
> SUCCESS [01:11 min]
> 17:14:29,313 INFO - df7-java-testgenerator ............................
> SUCCESS [01:10 min]
> 17:14:29,313 INFO - df7-wiki-testgenerator ............................
> SUCCESS [ 10.267 s]
> 17:14:29,324 ERROR - Internal error: java.lang.NegativeArraySizeException ->
> [Help 1]
> 17:14:29,327 ERROR - org.apache.maven.InternalErrorException: Internal error:
> java.lang.NegativeArraySizeException
> 17:14:29,327 ERROR - at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:167)
> 17:14:29,327 ERROR - at
> org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> 17:14:29,327 ERROR - at
> org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
> 17:14:29,327 ERROR - at
> org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
> 17:14:29,327 ERROR - at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 17:14:29,327 ERROR - at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 17:14:29,327 ERROR - at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 17:14:29,327 ERROR - at java.lang.reflect.Method.invoke(Method.java:606)
> 17:14:29,327 ERROR - at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> 17:14:29,327 ERROR - at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> 17:14:29,327 ERROR - at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> 17:14:29,327 ERROR - at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> 17:14:29,327 ERROR - Caused by: java.lang.NegativeArraySizeException
> 17:14:29,328 ERROR - at
> java.lang.AbstractStringBuilder.<init>(AbstractStringBuilder.java:64)
> 17:14:29,328 ERROR - at
> java.lang.StringBuilder.<init>(StringBuilder.java:97)
> 17:14:29,328 ERROR - at
> org.apache.maven.cli.event.ExecutionEventLogger.chars(ExecutionEventLogger.java:67)
> 17:14:29,328 ERROR - at
> org.apache.maven.cli.event.ExecutionEventLogger.logReactorSummary(ExecutionEventLogger.java:155)
> 17:14:29,328 ERROR - at
> org.apache.maven.cli.event.ExecutionEventLogger.sessionEnded(ExecutionEventLogger.java:111)
> 17:14:29,328 ERROR - at
> org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:64)
> 17:14:29,328 ERROR - at
> org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:42)
> 17:14:29,329 ERROR - at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:125)
> 17:14:29,329 ERROR - at
> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
> 17:14:29,329 ERROR - at
> org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> 17:14:29,329 ERROR - ... 11 more
> 17:14:29,329 ERROR -
> {code}
> It occurs not every build, but maybe every second or third.
> I downloaded the source tar.gz and found that indeed in line 155 of
> ExecutionEventLogger.java we have
> {code}
> 154: String buildTimeDuration = formatDuration(
> buildSummary.getTime() );
> 155: buffer.append( chars( ' ', BUILD_TIME_DURATION_LENGTH -
> buildTimeDuration.length() ) );
> {code}
> where
> {code}
> 47: private static final int BUILD_TIME_DURATION_LENGTH = 9;
> {code}
> However, in {{formatDuration}}, from {{CLIReportingUtils.java}} , it seems
> that the generated strings can well exceed this length:
> {code}
> 177: format = "%d d %02d:%02d h";
> {code}
> This has, as far as I understand, at least 6 characters, if we add two for
> minutes and minimum one for hour and one for day, this will already exceed
> the BUILD_TIME:DURATION_LENGTH. This seems an obvious bug to me.
> However our build times are usually less than one hour, so there must be some
> other reason for our strange long build time duration string.
> If the bug above was fixed, we could see better what's going on.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
