After upgrade to SQ 5.2, background task throws IllegalStateException

[Tyrel Haveman]

We recently upgraded our organization's SonarQube server to version 5.2 (from 5.1.1). Most things are working fine, but on one particular project, after the analysis is uploaded to the SonarQube server, the background task fails with this exception:

2015.12.03 05:43:41 ERROR [o.s.s.c.t.CeWorkerRunnableImpl] Failed to execute task AVFoFXr4tOKYAdi2XmBQ
java.lang.IllegalStateException: Changeset must have a date
        at com.google.common.base.Preconditions.checkState(Preconditions.java:176) ~[guava-17.0.jar:na]
        at org.sonar.server.computation.scm.ReportScmInfo.convert(ReportScmInfo.java:56) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.scm.ReportScmInfo.access$100(ReportScmInfo.java:40) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.scm.ReportScmInfo$LineIndexToChangeset.apply(ReportScmInfo.java:100) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.scm.ReportScmInfo$LineIndexToChangeset.apply(ReportScmInfo.java:84) ~[sonar-server-5.2.jar:na]
        at com.google.common.collect.Iterators$8.transform(Iterators.java:794) ~[guava-17.0.jar:na]
        at com.google.common.collect.TransformedIterator.next(TransformedIterator.java:48) ~[guava-17.0.jar:na]
        at com.google.common.collect.Iterators$7.computeNext(Iterators.java:646) ~[guava-17.0.jar:na]
        at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:143) ~[guava-17.0.jar:na]
        at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:138) ~[guava-17.0.jar:na]
        at com.google.common.collect.Iterators.addAll(Iterators.java:356) ~[guava-17.0.jar:na]
        at com.google.common.collect.Lists.newArrayList(Lists.java:147) ~[guava-17.0.jar:na]
        at com.google.common.collect.Iterables.toCollection(Iterables.java:337) ~[guava-17.0.jar:na]
        at com.google.common.collect.Iterables.toArray(Iterables.java:315) ~[guava-17.0.jar:na]
        at com.google.common.collect.FluentIterable.toArray(FluentIterable.java:436) ~[guava-17.0.jar:na]
        at org.sonar.server.computation.scm.ScmInfoImpl.<init>(ScmInfoImpl.java:43) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.scm.ReportScmInfo.convertToScmInfo(ReportScmInfo.java:49) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.scm.ReportScmInfo.<init>(ReportScmInfo.java:45) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.scm.ScmInfoRepositoryImpl.getScmInfoFromReport(ScmInfoRepositoryImpl.java:103) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.scm.ScmInfoRepositoryImpl.getScmInfoForComponent(ScmInfoRepositoryImpl.java:80) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.scm.ScmInfoRepositoryImpl.initializeScmInfoForComponent(ScmInfoRepositoryImpl.java:67) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.scm.ScmInfoRepositoryImpl.getScmInfo(ScmInfoRepositoryImpl.java:59) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.step.NewCoverageMeasuresStep$NewCoverageCounter.initialize(NewCoverageMeasuresStep.java:371) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.formula.FormulaExecutorComponentVisitor.processLeaf(FormulaExecutorComponentVisitor.java:165) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.formula.FormulaExecutorComponentVisitor.process(FormulaExecutorComponentVisitor.java:142) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.formula.FormulaExecutorComponentVisitor.visitFile(FormulaExecutorComponentVisitor.java:122) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.component.PathAwareCrawler.visitNode(PathAwareCrawler.java:89) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.component.PathAwareCrawler.visit(PathAwareCrawler.java:57) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.component.PathAwareCrawler.visitChildren(PathAwareCrawler.java:71) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.component.PathAwareCrawler.visit(PathAwareCrawler.java:54) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.component.PathAwareCrawler.visitChildren(PathAwareCrawler.java:71) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.component.PathAwareCrawler.visit(PathAwareCrawler.java:54) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.component.PathAwareCrawler.visitChildren(PathAwareCrawler.java:71) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.component.PathAwareCrawler.visit(PathAwareCrawler.java:54) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.component.PathAwareCrawler.visitChildren(PathAwareCrawler.java:71) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.component.PathAwareCrawler.visit(PathAwareCrawler.java:54) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.component.PathAwareCrawler.visitChildren(PathAwareCrawler.java:71) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.component.PathAwareCrawler.visit(PathAwareCrawler.java:54) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.step.NewCoverageMeasuresStep.execute(NewCoverageMeasuresStep.java:113) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.step.ComputationStepExecutor.execute(ComputationStepExecutor.java:39) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.taskprocessor.report.ReportTaskProcessor.process(ReportTaskProcessor.java:53) ~[sonar-server-5.2.jar:na]
        at org.sonar.server.computation.taskprocessor.CeWorkerRunnableImpl.executeTask(CeWorkerRunnableImpl.java:78) [sonar-server-5.2.jar:na]
        at org.sonar.server.computation.taskprocessor.CeWorkerRunnableImpl.run(CeWorkerRunnableImpl.java:55) [sonar-server-5.2.jar:na]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_67]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) [na:1.7.0_67]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) [na:1.7.0_67]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [na:1.7.0_67]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_67]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_67]
        at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]

I looked at the code in question, written by Sébastien Lesaint fairly recently. I'm not able to figure out why, given the information in the log (even with verbose on), there's a changeset without a date.

First of all, it would be helpful if, when this error happens, we could see what changeset it's talking about, in the log, so we might have an idea of what needs to be fixed.

Second, it'd be great to get this fixed. This might be exposing an underlying problem with the SCM code, I'm not sure. We're using Perforce currently.

Please let me know what additional details I can provide to help solve this. We'd really like to have our analysis working again.

Thanks!

Tyrel

[tyr...@gmail.com]

By the way, if it would be better for me to post this on StackOverflow, let me know and I will do that instead.

[Julien Lancelot]

Hi Tyrel,

Thanks for this feedback, I've created a ticket to improve the error message : https://jira.sonarsource.com/browse/SONAR-7114.

In SonarQube 5.3, thanks to https://jira.sonarsource.com/browse/SONAR-6997, you'll at least see the component key, but not the line.

In order for us to investigate, could you send us the log of the scanner (Maven, Sonar-runner, Ant, etc.) analysis ?

Thanks.

Regards,

Julien LANCELOT | SonarSource

http://sonarsource.com

On 3 December 2015 at 21:37, <tyr...@gmail.com> wrote:

By the way, if it would be better for me to post this on StackOverflow, let me know and I will do that instead.

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/0077d857-e213-4374-b341-9c03ad364a4f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Tyrel Haveman]

Thanks for responding and creating those issues. I have attached the build log, as requested. (I replaced product and company names in it with "ourproduct", "ourcompany", etc.)

Let me know if there's anything else I can provide to help debug this.

Thanks,

Tyrel

You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/Z4D-n9eQ0Ts/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/CADxMB_M3hPoL19Q%3DN4-uj-5TRVK1PmRBN%2Bvrn0a8Les1-3kJbg%40mail.gmail.com.

[wbar...@gmail.com]

Hi guys, do you have any progress on this? We are getting the same issue after upgrading to SQ 5.2.
Just disabling scm (-Dsonar.scm.disabled=true) improved the situation a bit, but we loose  some statistics in this case.
------------------------

пятница, 4 декабря 2015 г., 17:01:24 UTC+3 пользователь Julien Lancelot написал:

[tyr...@gmail.com]

We also disabled SCM in order to continue getting work done, but it's definitely caused other issues since we don't know who has done what anymore.

Hopefully someone can figure this out sooner than later.

I'm curious if you're also using Perforce for SCM?

[wbar...@gmail.com]

Exactly we use Perforce. Yes, it is not good to look at the issues and code changes and have no ability to
understand who exactly made the change. Sure we use Perforce client in parallel, but getting the final decision about what and why
takes many time. It can help us if we enable SQ for CI builds (so we can get new issues immediately on builds), but we have no such ability yet
while the new product is not in best shape, otherwise we have to fail each check-in.

[wbar...@gmail.com]

In addition: we tried to use Jenkins plugin and run the task from there using the plugin. It is strange but it
completed w/o any issues, results were published to SQ server. I guess tehre is some workaround inside the plugin which
makes this task successfully processed.

[wbar...@gmail.com]

I compared the logs produced on Jenkins (by SQ plugin) and in shell by sonar-runner - they do not have sufficient difference which can
show us a possible reason of the breakage. I also tried to use 1.8 jdk instead of 1.7 - no luck as well

[wbar...@gmail.com]

Comparing logs taken from background tasks of successful and failed jobs I found that fails happened right after
"Compute size measures" and before or on "Compute new coverage". So I supposed some measures can lead to this fail.
I removed all measures I created before and rerun the build - no luck, result is the same.
Any updates on this, guys?

successful job:
2015.12.24 09:31:51 INFO  [o.s.s.c.s.ComputationStepExecutor] Log scanner context | time=40ms
2015.12.24 09:31:51 INFO  [o.s.s.c.s.ComputationStepExecutor] Build tree of components | time=78ms
2015.12.24 09:31:51 INFO  [o.s.s.c.s.ComputationStepExecutor] Validate project | time=3ms
2015.12.24 09:31:51 INFO  [o.s.s.c.s.ComputationStepExecutor] Load debt model | time=1ms
2015.12.24 09:31:51 INFO  [o.s.s.c.s.ComputationStepExecutor] Load quality profiles | time=145ms
2015.12.24 09:31:51 INFO  [o.s.s.c.s.ComputationStepExecutor] Load Quality gate | time=1ms
2015.12.24 09:31:51 INFO  [o.s.s.c.s.ComputationStepExecutor] Load differential periods | time=11ms
2015.12.24 09:31:51 INFO  [o.s.s.c.s.ComputationStepExecutor] Compute size measures | time=109ms
2015.12.24 09:31:52 INFO  [o.s.s.c.s.ComputationStepExecutor] Compute new coverage | time=981ms
2015.12.24 09:31:52 INFO  [o.s.s.c.s.ComputationStepExecutor] Compute coverage measures | time=30ms
....

failed job:
2015.12.23 23:08:13 INFO  [o.s.s.c.s.ComputationStepExecutor] Log scanner context | time=14ms
2015.12.23 23:08:13 INFO  [o.s.s.c.s.ComputationStepExecutor] Build tree of components | time=165ms
2015.12.23 23:08:13 INFO  [o.s.s.c.s.ComputationStepExecutor] Validate project | time=8ms
2015.12.23 23:08:13 INFO  [o.s.s.c.s.ComputationStepExecutor] Load debt model | time=5ms
2015.12.23 23:08:13 INFO  [o.s.s.c.s.ComputationStepExecutor] Load quality profiles | time=232ms
2015.12.23 23:08:13 INFO  [o.s.s.c.s.ComputationStepExecutor] Load Quality gate | time=2ms
2015.12.23 23:08:13 INFO  [o.s.s.c.s.ComputationStepExecutor] Load differential periods | time=38ms
2015.12.23 23:08:14 INFO  [o.s.s.c.s.ComputationStepExecutor] Compute size measures | time=459ms
2015.12.23 23:08:14 ERROR [o.s.s.c.t.CeWorkerRunnableImpl] Failed to execute task AVHQPdLXH5pyoGbVF4Ip

java.lang.IllegalStateException: Changeset must have a date

[Julien Lancelot]

Hi,

It seems that Perforce has created bad commit without date.

Could you try SonarQube 5.3-RC2 ? It will allow to know which file has a bad SCM info, then you'll be able to look at the SCM data of the file.

Regards,

Julien LANCELOT | SonarSource

http://sonarsource.com

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/9bb92b2c-07f5-41dc-ad8a-cd92574958d0%40googlegroups.com.

[Tyrel Haveman]

I have upgraded to 5.3-RC2 and run a build. The build log now shows the filelog and annotate commands being run against perforce for 5 different files, theen says 4/30 files analyzed. Next it says "Missing blame information for the following files:" and gives a large list of files (26).

The error printed at the end says: Blame date is null for file src/main/java/com/ourcompany/ourproduct/auth/security/CoreCredentialVerifier.java

I've attached that log as "sonar 53 log.txt"

If I run the last commands that it ran, manually, I get the output you see in "filelog.txt". Every changelist shown here has a date on it.

However, it is worth noting that the first changelist number (the last in the log if you're reading top to bottom) is actually a changelist number on a DIFFERENT Perforce server. This file was imported (branched) from one Perforce server to another; in the process, some information was lost. That's why it says "remote@remote" as the user and workspace names (that's what it puts when you import in this manner). The correct thing to do in this situation would be to ignore that revision. But in any case, the date is on it so I'm not sure why SonarQube is having trouble with it.

Let me know if there's anything else I can provide to help. Hopefully this can get fixed in 5.3 so we don't have to keep SCM turned off!

Thanks,

Tyrel

[Julien HENRY]

Hi Tyrel,

That's a very interesting feedback. I was already working on fixing a similar issue with the help of Matthew DeTullio. Would you mind testing this updated version of the perforce plugin:

https://github.com/SonarSource/sonar-scm-perforce/releases/download/1.3-rc1/sonar-scm-perforce-plugin-1.3-SNAPSHOT.jar

Matthew changed the strategy to no more use p4 filelog command but instead use p4 change -o on each changelist referenced by p4 annotate.

Could you please report any success/issue directly on the pull request:

https://github.com/SonarSource/sonar-scm-perforce/pull/7

Thanks

Julien

Le mardi 5 janvier 2016 00:24:25 UTC+1, Tyrel Haveman a écrit :

I have upgraded to 5.3-RC2 and run a build. The build log now shows the filelog and annotate commands being run against perforce for 5 different files, theen says 4/30 files analyzed. Next it says "Missing blame information for the following files:" and gives a large list of files (26).

The error printed at the end says: Blame date is null for file src/main/java/com/ourcompany/ourproduct/auth/security/CoreCredentialVerifier.java

I've attached that log as "sonar 53 log.txt"

If I run the last commands that it ran, manually, I get the output you see in "filelog.txt". Every changelist shown here has a date on it.

However, it is worth noting that the first changelist number (the last in the log if you're reading top to bottom) is actually a changelist number on a DIFFERENT Perforce server. This file was imported (branched) from one Perforce server to another; in the process, some information was lost. That's why it says "remote@remote" as the user and workspace names (that's what it puts when you import in this manner). The correct thing to do in this situation would be to ignore that revision. But in any case, the date is on it so I'm not sure why SonarQube is having trouble with it.

Let me know if there's anything else I can provide to help. Hopefully this can get fixed in 5.3 so we don't have to keep SCM turned off!

Thanks,

Tyrel

To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/9bb92b2c-07f5-41dc-ad8a-cd92574958d0%40googlegroups.com.

[Tyrel Haveman]

Thanks. I have tried it and added a comment to the pull request (it doesn't fix anything, and possibly makes it worse).

Tyrel

On Tue, Jan 5, 2016 at 12:38 AM Julien HENRY <julien...@sonarsource.com> wrote:

Hi Tyrel,

That's a very interesting feedback. I was already working on fixing a similar issue with the help of Matthew DeTullio. Would you mind testing this updated version of the perforce plugin:

https://github.com/SonarSource/sonar-scm-perforce/releases/download/1.3-rc1/sonar-scm-perforce-plugin-1.3-SNAPSHOT.jar

Matthew changed the strategy to no more use p4 filelog command but instead use p4 change -o on each changelist referenced by p4 annotate.

Could you please report any success/issue directly on the pull request:

https://github.com/SonarSource/sonar-scm-perforce/pull/7

Thanks

Julien

Le mardi 5 janvier 2016 00:24:25 UTC+1, Tyrel Haveman a écrit :

I have upgraded to 5.3-RC2 and run a build. The build log now shows the filelog and annotate commands being run against perforce for 5 different files, theen says 4/30 files analyzed. Next it says "Missing blame information for the following files:" and gives a large list of files (26).

The error printed at the end says: Blame date is null for file src/main/java/com/ourcompany/ourproduct/auth/security/CoreCredentialVerifier.java

I've attached that log as "sonar 53 log.txt"

If I run the last commands that it ran, manually, I get the output you see in "filelog.txt". Every changelist shown here has a date on it.

However, it is worth noting that the first changelist number (the last in the log if you're reading top to bottom) is actually a changelist number on a DIFFERENT Perforce server. This file was imported (branched) from one Perforce server to another; in the process, some information was lost. That's why it says "remote@remote" as the user and workspace names (that's what it puts when you import in this manner). The correct thing to do in this situation would be to ignore that revision. But in any case, the date is on it so I'm not sure why SonarQube is having trouble with it.

Let me know if there's anything else I can provide to help. Hopefully this can get fixed in 5.3 so we don't have to keep SCM turned off!

Thanks,

Tyrel

To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/9bb92b2c-07f5-41dc-ad8a-cd92574958d0%40googlegroups.com.

[Tyrel Haveman]

Thanks to Matthew's help, pull requests #7 and #9 (combined) on sonar-scm-perforce will fix my issues when running with 5.3-RC2. I'm running for now with those built locally and look forward to an official build of the perforce plugin that includes those.

Thanks!

Tyrel

[Julien HENRY]

Cool, I'll start a vote soon.

[wbar...@gmail.com]

Nice to hear that it works for you finally. I've been in a long holidays, just back to work and will check how it is for me now. I guess I need to upgrade to SQ 5.3 along with Perforce plugin - I see v1.3 is ready to install.
Let you know then the results, hope all should be fine. Thanks guys for the efforts.

[wbar...@gmail.com]

Guys, now it works fine for me, just for some reason for one project I had to use -Dsonar.scm.forceReloadAll=true to load perforce data related to the project.
Thank you all

[wbar...@gmail.com]

Unfortunately, we get the following during the big project analysis

ERROR: Error during Sonar runner execution
ERROR: Unable to execute Sonar
ERROR: Caused by: java.net.SocketTimeoutException: Read timed out

The rest works almost fine except Sonar now is strictly depends on in which folder a project was built and in which folder we start sonar analysis

[Julien HENRY]

Hi,

Do you have the full stack trace?

++

Julien

[wbar...@gmail.com]

Hi Julien, I've made more investigation when this happened and found that this found after a long process of collecting perforce data completed (about 4500 files)
This happened not when analysis is done and the report sent to server but during the analysis of the component of the project.
I understand this probably explains you nothing. Please tell me what data to collect for you and I'll do.
If I do not use scm analysis - all is fine.

[Matthew DeTullio]

Try setting sonar.perforce.sockSoTimeout to something like 60000 or possibly higher depending on performance of all services involved (including network connectivity).  The default is 30000.

You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/Z4D-n9eQ0Ts/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/829d5807-744f-4d2c-9643-7b17ff43d4be%40googlegroups.com.

[wbar...@gmail.com]

Hi Matthew,

thank you a lot, I set the property to 60000 and this helped!
Looks like we have periodical short network connectivity interruptions.

Let me know what if I used the property with such increased value by default, for all projects even some of them are small in size?
How it can impact something like server or a host where sonar-runner works?

Dmitry

[Matthew DeTullio]

The setting changes how long to wait for any one perforce command to get a response from the perforce server during analysis.  There's no harm to increasing it unless network problems are common, then a high timeout will just prolong the time to failure

[wbar...@gmail.com]

Understood, thank you so much.

[Tyrel Haveman]

We have encountered additional issues with the annotation (blame) process in Perforce on another team at my company. I've made some modifications to the code and offered a pull request which optimizes the process. We've tested this on both teams encountering issues and it's working. https://github.com/SonarSource/sonar-scm-perforce/pull/10

The Travis CI build failed on my pull request but it doesn't seem to have anything to do with the changes:

   ./travis.sh: line 34: GITHUB_TOKEN: unbound variable

[wbar...@gmail.com]

Hey guys,

even I set sonar.perforce.sockSoTimeout to 120000 already, I'm getting the same issue (see below)
 

[03:45:10][Step 73/74] 16:44:56.779 INFO - 0/15 files analyzed

[03:45:10][Step 73/74] 16:44:56.779 WARN - Missing blame information for the following files:

[03:45:10][Step 73/74] 16:44:56.779 WARN - * /home/five9inf/build/sources/releases/9.2/mainframe/zion/source/java/com/five9/cc/ui/common/FieldViewsUtils.java

[03:45:10][Step 73/74] 16:44:56.779 WARN - * /home/five9inf/build/sources/releases/9.2/mainframe/zion/source/java/com/five9/inf/crm/structure/StaticFieldInfoImpl.java

[03:45:10][Step 73/74] 16:44:56.779 WARN - * /home/five9inf/build/sources/releases/9.2/mainframe/zion/source/test/java/com/five9/cc/spi/CCExtendedAgentSessionImplTest.java

[03:45:10][Step 73/74] 16:44:56.779 WARN - * /home/five9inf/build/sources/releases/9.2/mainframe/zion/source/java/com/five9/inf/crm/structure/CrmFieldInfoImpl.java

[03:45:10][Step 73/74] 16:44:56.779 WARN - * /home/five9inf/build/sources/releases/9.2/mainframe/zion/source/java/com/five9/inf/crm/structure/NamesNarrowTableStructure.java

[03:45:10][Step 73/74] 16:44:56.779 WARN - * /home/five9inf/build/sources/releases/9.2/mainframe/zion/source/java/com/five9/inf/interfaces/NoValidNumberException.java

[03:45:10][Step 73/74] 16:44:56.779 WARN - * /home/five9inf/build/sources/releases/9.2/mainframe/zion/source/java/com/five9/inf/interfaces/CRMRecordValidationException.java

[03:45:10][Step 73/74] 16:44:56.779 WARN - * /home/five9inf/build/sources/releases/9.2/mainframe/zion/source/test/java/com/five9/cc/spi/CCSessionTestUtils.java

[03:45:10][Step 73/74] 16:44:56.779 WARN - * /home/five9inf/build/sources/releases/9.2/mainframe/zion/source/java/com/five9/inf/report/server/datasources/TextDataSource.java

[03:45:10][Step 73/74] 16:44:56.779 WARN - * /home/five9inf/build/sources/releases/9.2/mainframe/zion/source/java/com/five9/cc/spi/CCExtendedAgentSessionImpl.java

[03:45:10][Step 73/74] 16:44:56.779 WARN - * /home/five9inf/build/sources/releases/9.2/mainframe/zion/source/java/com/five9/inf/crm/CRMNamedNarrowTable.java

[03:45:10][Step 73/74] 16:44:56.779 WARN - * /home/five9inf/build/sources/releases/9.2/mainframe/zion/source/java/com/five9/inf/ejb/EJBService.java

[03:45:10][Step 73/74] 16:44:56.779 WARN - * /home/five9inf/build/sources/releases/9.2/mainframe/zion/source/java/com/five9/inf/interfaces/CompanyConstants.java

[03:45:10][Step 73/74] 16:44:56.779 WARN - * /home/five9inf/build/sources/releases/9.2/mainframe/zion/source/java/com/five9/cc/datatype/common/validator/exceptions/ReadOnlyValueException.java

[03:45:10][Step 73/74] 16:44:56.779 WARN - * /home/five9inf/build/sources/releases/9.2/mainframe/zion/source/java/com/five9/cc/interfaces/CCExtendedAgentSession.java

[03:45:10][Step 73/74] 16:44:56.779 WARN - This may lead to missing/broken features in SonarQube

[03:45:11][Step 73/74] INFO: ------------------------------------------------------------------------

[03:45:11][Step 73/74] INFO: EXECUTION FAILURE

[03:45:11][Step 73/74] INFO: ------------------------------------------------------------------------

[03:45:11][Step 73/74] Total time: 23:40.129s

[03:45:11][Step 73/74] ERROR: Error during Sonar runner execution

[03:45:11][Step 73/74] ERROR: Unable to execute Sonar

[03:45:11][Step 73/74] ERROR: Caused by: java.net.SocketTimeoutException: Read timed out

[03:45:11][Step 73/74] ERROR:

[03:45:11][Step 73/74] ERROR: To see the full stack trace of the errors, re-run SonarQube Runner with the -e switch.

[03:45:11][Step 73/74] ERROR: Re-run SonarQube Runner using the -X switch to enable full debug logging.

At the same time the execution is OK on the same or more number of files for another product build. There is just one difference in environment -
the old product (which fails) compiles the code in Centos 5.10, the new one is in Centos 6.x. Maybe the reason is in here? Current SQ setup is
SQ 5.3 server and Perforce scm plugin v1.4. I haven't upgraded to SQ 5.4, but if you confirm it can help to resolve the issue, I'll do it asap.
Thanks!

[Matthew DeTullio]

Socket timeout is per file, so the Perforce server may be taking a long time to retrieve history or annotate a specific file.  Keep increasing the timeout value.

--
You received this message because you are subscribed to a topic in the Google Groups "SonarQube" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sonarqube/Z4D-n9eQ0Ts/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sonarqube+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/a036df1b-fbef-4aec-bdf5-4ee8edfdcefb%40googlegroups.com.

[wbar...@gmail.com]

Thank you, Matt. Once I upgraded Sonar to 5.4 I have no failed builds. Keep my fingers crossed, hope this helped.

понедельник, 14 марта 2016 г., 17:02:01 UTC+3 пользователь Matthew DeTullio написал: