Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 354017

Summary: Intermittent failures in tests after I20110803-1800
Product: [Eclipse Project] PDE Reporter: Curtis Windatt <curtis.windatt.public>
Component: API ToolsAssignee: PDE API Tools Inbox <pde-apitools-inbox>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: daniel_megert, Michael_Rennie, Olivier_Thomann
Version: 3.7Flags: Olivier_Thomann: review+
Target Milestone: 3.8 M2   
Hardware: PC   
OS: Linux   
Whiteboard:
Bug Depends on:    
Bug Blocks: 355152    
Attachments:
Description Flags
Fix for performance issue none

Description Curtis Windatt CLA 2011-08-05 11:22:11 EDT
testUnusedFilter1I	Failure	Wrong number of problems expected:<1> but was:<0>

junit.framework.AssertionFailedError: Wrong number of problems expected:<1> but was:<0>
at org.eclipse.pde.api.tools.builder.tests.ApiBuilderTest.assertProblems(ApiBuilderTest.java:418)
at org.eclipse.pde.api.tools.builder.tests.usage.UnusedApiProblemFilterTests.deployTest(UnusedApiProblemFilterTests.java:183)
at org.eclipse.pde.api.tools.builder.tests.usage.UnusedApiProblemFilterTests.x1(UnusedApiProblemFilterTests.java:208)
at org.eclipse.pde.api.tools.builder.tests.usage.UnusedApiProblemFilterTests.testUnusedFilter1I(UnusedApiProblemFilterTests.java:195)
at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:501)
at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:259)
at org.eclipse.test.CoreTestApplication.runTests(CoreTestApplication.java:36)
at org.eclipse.test.CoreTestApplication.run(CoreTestApplication.java:32)
at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
at org.eclipse.core.launcher.Main.main(Main.java:34)

testImportJavadocTestSource	Failure	the test project api component must exist in the workspace baseline

junit.framework.AssertionFailedError: the test project api component must exist in the workspace baseline
at org.eclipse.pde.api.tools.tests.AbstractApiTest.createProject(AbstractApiTest.java:147)
at org.eclipse.pde.api.tools.util.tests.ProjectCreationTests.setUp(ProjectCreationTests.java:60)
at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:501)
at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:259)
at org.eclipse.test.CoreTestApplication.runTests(CoreTestApplication.java:36)
at org.eclipse.test.CoreTestApplication.run(CoreTestApplication.java:32)
at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577)
at org.eclipse.equinox.launcher.Main.run(Main.java:1410)
at org.eclipse.equinox.launcher.Main.main(Main.java:1386)
at org.eclipse.core.launcher.Main.main(Main.java:34)
Comment 1 Curtis Windatt CLA 2011-08-10 14:48:43 EDT
The possibility of these failures have existing for quite some time.  They are surfaced more frequently now that the tests recreate the workspace projects for each test.

The problem is that a required project, refproject, is not finished building before the Api Builder runs on usageproject.  So our builder aborts.  The JDT problem is:

[sourceId, JDT, categoryId, 10, message, The project cannot be built until its prerequisite refproject is built. Cleaning and building all projects is recommended, severity, 2]

I suspected that maybe some of the builder optmizations added in 3.7 were causing refproject to not be built, however I ran the current tests against older 3.6 api tools bundles and the tests still fail in the same manner.

Olivier/Dani, can either of you comment on why refproject might not be built?  I can only reproduce the issue consistently in Windows.
Comment 2 Curtis Windatt CLA 2011-08-10 15:16:43 EDT
During all of the builds, no builder ever runs on refproject (when the test is failing).

The tests also end up doing full builds three times
1) When we first create the environment (perhaps the JDT tests we extend are kicking this off)
2) When we finish importing the projects (controlled by boolean flag, some tests have it set to true)
3) When we deploy the test, after adding whatever file we are testing

This seems like a waste.
Comment 3 Curtis Windatt CLA 2011-08-12 14:53:22 EDT
Is Olivier away?  Dani, can you help investigate?
Comment 4 Dani Megert CLA 2011-08-12 16:16:56 EDT
(In reply to comment #3)
> Is Olivier away?  Dani, can you help investigate?
yep, Olivier is on vacation. I'll see what I can do to help on Monday.
Comment 5 Dani Megert CLA 2011-08-15 06:23:13 EDT
Maybe related to bug 305732?

You could also try to disable auto-build and then do a full build when ready.

Olivier should be back today for more detailed feedback.
Comment 6 Curtis Windatt CLA 2011-08-17 17:29:44 EDT
Created attachment 201675 [details]
Fix for performance issue

This patch corrects a change in the setup method of usage tests that avoids re-importing refproject for each test.  The usage tests clean up their actual test classes (from usageproject), so they do not contaminate each other.  This fix vastly improves the time it takes to run the usage tests.

Olivier had suggested I look into using JUnit4 annotations to only create the projects once for each test class. This fix makes that approach unnecessary for the usage tests.  In bug 349706 I had to change several tests to create and cleanup their test projects for each test run (ProjectCreationTests, PreferenceTests, and ApiDescriptionProcessorTests).  Taking this approach with these tests is possible, but would only increase performance of the whole suite by a few seconds and the tests would have to be much more careful about cleaning up any preferences/options they modify. I don't believe it is worthwhile to change them.

I still have not been able to find the root cause of the failure to build refproject. If Olivier has some time on a WinXP machine he will take a second look.

For now, I am applying this fix to HEAD to see if it allows the tests to pass in the next nightly build.  If so, we should release it to 3.7.1 before RC2.
Comment 7 Curtis Windatt CLA 2011-08-22 12:57:04 EDT
Olivier, do you have time today to review the performance fix for 3.7.1 inclusion?
Comment 8 Curtis Windatt CLA 2011-08-22 12:58:03 EDT
(In reply to comment #6)
> For now, I am applying this fix to HEAD to see if it allows the tests to pass
> in the next nightly build.  If so, we should release it to 3.7.1 before RC2.

The tests passed in the nightly builds.  We had one intermittent failure on the MAc machine unrelated to this bug.
Comment 9 Olivier Thomann CLA 2011-08-22 13:17:46 EDT
This change is fine, but I don't think this is sufficient. It doesn't hurt to release that code. We might have to do more changes in the past to get more reliable test results.
Comment 10 Curtis Windatt CLA 2011-08-22 15:10:09 EDT
The fix is in the R3_7_maintenance.
Comment 11 Curtis Windatt CLA 2011-08-25 15:05:23 EDT
This bug was cloned for 3.7.1 inclusion.  Correcting the milestone.
Comment 12 Curtis Windatt CLA 2011-09-14 14:37:11 EDT
Applying this fix has stopped the intermittent failures for many builds.  Marking as VERIFIED.