Bug 802437 - Arquillian framework @RunDiscovery annotation issue
Summary: Arquillian framework @RunDiscovery annotation issue
Keywords:
Status: ON_QA
Alias: None
Product: RHQ Project
Classification: Other
Component: Tests
Version: 4.3
Hardware: All
OS: All
unspecified
medium
Target Milestone: ---
: ---
Assignee: Nobody
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-03-12 14:36 UTC by Jay Shaughnessy
Modified: 2024-03-04 13:35 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)
trace showing issues (22.04 KB, application/octet-stream)
2012-03-12 14:36 UTC, Jay Shaughnessy
no flags Details

Description Jay Shaughnessy 2012-03-12 14:36:53 UTC
Created attachment 569424 [details]
trace showing issues

This falls somewhere between bug and enhancement. When using the @RunDiscovery annotation with a multi-level hierarchy, and the need to "mock-import" the
resources (i.e. set them to COMMITTED), discovery work runs past the start
of the test invocation.

We need a mechanism to import discovered resources and have it complete
prior to a test running, as this is logically part of the test setup.

At the moment I workaround this with a 10s sleep at the start of the test.
This can be seen currently in the jshaughn/avail branch, and the AvailTest
setup.  But the gist is that we have:

@BeforeDiscovery
public void resetServerServices() throws Exception {
   serverServices.resetMocks();
   fakeServerInventory = new FakeServerInventory();

   // autoimport everything
   when(serverServices.getDiscoveryServerService().mergeInventoryReport(
      any(InventoryReport.class))).then(
          fakeServerInventory.mergeInventoryReport(InventoryStatus.COMMITTED));
}

Comment 1 Jay Shaughnessy 2012-03-12 14:52:26 UTC
...continuing from above...

In the attachment you can see some odd behavior:

Lines 1-124
Test setup, and you can see the RunDiscovery stuff happening.

Line 127
This shows the BeforeMethod method executing prior to the first test (which
has the @RunDiscovery annotation.

Line 129
The very first thing this test does is sleep for 10 seconds, this println
marks the start of the sleep period.

Lines 130-147 (PROBLEM)
Note that after a 5s delay from line 124 (a timeout?) we get  more discovery,
more avail runs, etc... It ends prior to the sleep finishing.

Line 150
The sleep ends and the test continues, and passes.

Line 152+
This just shows that the next test is starting, with no more interference.

One note - See that there are *6* log entries stating:

  "Executing runtime discovery scan rooted at [platform]..."

Three prior to the test start and three during the sleep period. And each
follows with an Avail scan.  This seems like a lot...

Comment 2 Lukas Krejci 2012-03-12 15:42:10 UTC
The scan for child resources is scheduled with a delay of 5s. This is hardcoded in the InventoryManager.synchInventory(ResourceSyncInfo) method.

I suggest to make this attribute configurable and set its value to 0s for the tests so that we get immediate child resource discovery. 

Note that even with this change the child discovery will still be async and will be done a level at a time (and thus we are still going to need some "@AfterDiscovery" magic in the test methods as we discussed on the phone).

Comment 3 Mike Foley 2012-03-12 15:42:43 UTC
per BZ traige (crouch, foley, loleary), medium priority, not targetted for JON 3.1

Comment 4 Lukas Krejci 2012-03-12 20:05:38 UTC
commit bf5c34f5e3bea4c520853ddf2be4161f77e361ca
Author: Lukas Krejci <lkrejci>
Date:   Mon Mar 12 20:58:06 2012 +0100

    [BZ 802437] Adding another lifecycle stage to the RHQ arquillian tests making it
    possible to "recover" the PC from the effect of running operations on it.
    By default the @AfterDiscovery handler is added to this stage which enables
    tests to hook into the test execution right after the discovery has run
    but before the actual test methods occur.
    
    Added a utility approach in FakeServerInventory to wait until async child
    resource discoveries are finished.

Comment 5 Lukas Krejci 2012-03-12 20:07:10 UTC
The note about the hardcoded 5s child resource discovery delay has been captured in a stadalone bug 802550.


Note You need to log in before you can comment on or make changes to this bug.