[wildfly-dev] smoke testing failure
Brian Stansberry
brian.stansberry at redhat.com
Tue Oct 21 18:28:21 EDT 2014
On 10/21/14, 3:19 PM, Brian Stansberry wrote:
> Thanks, Jaikiran.
>
> I think this is almost certainly due to these:
>
> testFilesystemDeployment_Marker()
> testFilesystemDeployment_Auto()
>
> All implement the test's utility class' DeploymentExecutor.undeploy()
> method by deleting a file in a deployment scanner directory, and then
> don't wait to validate the completion of scanner execution. In each of
> those three the testDeployments method can return once the deployment is
> out of the runtime and therefore no longer visible via JMX but before
> the completion of the management op. The removal from the content
> repository is done as part of completion of the management op. (It's not
> a background process.)
>
> This is a problem that went undetected for years because the scanner was
> treating zips as non-managed deployments, and not uploading them to the
> content repo. That was recently changed.
>
> I think the fix is to have those DeploymentExecutor.undeploy() methods
> block until the .undeployed marker file appears or some reasonable
> timeout happens.
>
https://issues.jboss.org/browse/WFLY-4005
Fix is https://github.com/wildfly/wildfly/pull/6851
> OT: every test in this package needs to be moved to the wildfly-core
> testsuite.
https://issues.jboss.org/browse/WFCORE-193 if anyone wants to take that on
>
> On 10/20/14, 4:26 AM, Jaikiran Pai wrote:
>> Saw the same issue locally and from what I see in that testcase, it
>> doesn't appear to be a JVM vendor/version issue. This actually is a race
>> condition in the test method execution and removal of content from
>> content repository.
>>
>> That ServerInModuleDeploymentTestCase testcase has multiple test methods
>> which deal with deploying and undeploying. From what I am observing it
>> looks like one of the test methods first runs (I guess the
>> testDeploymentFileApi) and does its deploy/undeploy sequence and then
>> the testDeploymentStreamApi runs which first does a file listing of the
>> content directory and turns out the undeploy operation from the previous
>> test method hasn't yet removed the content from the content repository
>> yet. So this test picks up those (to be deleted) hashes as initial
>> hashes in the content repo. While this test method is running, a
>> background thread cleans up previously undeployed the hashes from the
>> content repository. As a result a subsequent file listing of the content
>> directory from this current test method doesn't find those expected
>> initial hashes.
>>
>> I'm not sure what the expected behaviour of a undeploy operation is -
>> whether the undeploy should complete only after the content has been
>> removed (probably not) from the content repository or whether it can
>> return before that (as it seems to be happening now).
>>
>> FWIW, here's my environment details:
>>
>> java version "1.7.0_15"
>> Java(TM) SE Runtime Environment (build 1.7.0_15-b03)
>> Java HotSpot(TM) Server VM (build 23.7-b01, mixed mode)
>>
>> Tests run: 6, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 10.618
>> sec <<< FAILURE! - in
>> org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase
>> testDeploymentStreamApi(org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase)
>> Time elapsed: 0.473 sec <<< FAILURE!
>> java.lang.AssertionError:
>> expected:<[29c4c47c1224a00169a8df02d84c3d6ff014b5fb,
>> b9227c99efad4b615df0ad5288b6690216ed7bad]> but
>> was:<[29c4c47c1224a00169a8df02d84c3d6ff014b5fb]>
>> at org.junit.Assert.fail(Assert.java:88)
>> at org.junit.Assert.failNotEquals(Assert.java:743)
>> at org.junit.Assert.assertEquals(Assert.java:118)
>> at org.junit.Assert.assertEquals(Assert.java:144)
>> at
>> org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase.testDeployments(ServerInModuleDeploymentTestCase.java:618)
>> at
>> org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase.testDeploymentStreamApi(ServerInModuleDeploymentTestCase.java:96)
>>
>>
>> -Jaikiran
>> On Wednesday 15 October 2014 06:28 PM, Eduardo Sant´Ana da Silva wrote:
>>> Could be some change regarding some message digest used on ShrinkWrap
>>> API based upon a different JVM version?
>>>
>>> Just a guess...
>>>
>>> ---
>>> Eduardo Sant'Ana da Silva
>>>
>>> 2014-10-15 1:40 GMT-03:00 Peter Cai <qutpeter at gmail.com
>>> <mailto:qutpeter at gmail.com>>:
>>>
>>> Well, I have no luck on tracking down what is happening in this
>>> test case.
>>> But things is becoming more interesting.
>>> I can partially repeat the failure on Windows 8.
>>> Now, on both Ubuntu 14.04 and Windows 8, using JVM 1.7.0_51,
>>> run the test from the smoke testing module. i.e.,
>>> cd testsuite\integration\smoke
>>> mvn clean test
>>> -Dtest=org.jboss.as.test.smoke.mgmt.servermodule.ServerInModuleDeploymentTestCase
>>> Interestingly, this testcase sometimes passes, sometimes fails.
>>> When failed, with the following info:
>>> Failed tests:
>>> ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614
>>> expected:<[504917ff8990a5f90995d412117e39afbdaf6747]> but was:<[]>
>>> Regards,
>>> Peter
>>>
>>> On Tue, Oct 14, 2014 at 10:33 PM, Peter Cai <qutpeter at gmail.com
>>> <mailto:qutpeter at gmail.com>> wrote:
>>>
>>> On my side, I use "mvn -fae -Dmaven.test.failure.ignore=true
>>> clean install", this test mentioned above is the only test
>>> that failed.
>>>
>>> I am trying to track it down.
>>>
>>> Regards,
>>> Peter
>>>
>>> On Tue, Oct 14, 2014 at 7:23 PM, Tomaž Cerar
>>> <tomaz.cerar at gmail.com <mailto:tomaz.cerar at gmail.com>> wrote:
>>>
>>> Guys, is problem only this test or also something else?
>>>
>>> it is possible that this tests has problems that makes it
>>> fail on certain scenarios.
>>>
>>> Any chance anyone of you that can reproduce it, can try to
>>> track it down what the issue is?
>>>
>>> if you add "-fae -Dmaven.test.failure.ignore=true " as
>>> param to build, it will continue building/testing after
>>> test failure(s),
>>> so you can see what all tests fail for you or only this one.
>>>
>>> On Tue, Oct 14, 2014 at 7:19 AM, Edward Wertz
>>> <ewertz at redhat.com <mailto:ewertz at redhat.com>> wrote:
>>>
>>> I've gotten that error for a while, so you're not
>>> alone, but haven't been able to track it down either,
>>> so I'm not much help fixing it. Java/Maven versions
>>> don't effect it and I can build fine on my Windows 7
>>> machine. It's a mystery to me what's causing it.
>>>
>>> Linux localhost.localdomain 3.16.2-201.fc20.x86_64 #1
>>> SMP Mon Sep 15 19:57:50 UTC 2014 x86_64 x86_64 x86_64
>>> GNU/Linux
>>> LSB Version:
>>> :core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
>>> Distributor ID: Fedora
>>> Description: Fedora release 20 (Heisenbug)
>>> Release: 20
>>> Codename: Heisenbug
>>>
>>> Joe Wertz
>>>
>>>
>>> ----- Original Message -----
>>> > From: "Eduardo Sant´Ana da Silva"
>>> <eduardo.santanadasilva at gmail.com
>>> <mailto:eduardo.santanadasilva at gmail.com>>
>>> > To: "Peter Cai" <qutpeter at gmail.com
>>> <mailto:qutpeter at gmail.com>>
>>> > Cc: wildfly-dev at lists.jboss.org
>>> <mailto:wildfly-dev at lists.jboss.org>
>>> > Sent: Tuesday, October 14, 2014 8:29:11 AM
>>> > Subject: Re: [wildfly-dev] smoke testing failure
>>> >
>>> >
>>> >
>>> > I've made the build successfully on the following
>>> environment as
>>> > well:
>>> >
>>> > OS X 10.9.5
>>> > java version "1.8.0_05"
>>> > Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
>>> > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02,
>>> mixed mode)
>>> >
>>> >
>>> > 2014-10-13 20:19 GMT-03:00 Peter Cai <
>>> qutpeter at gmail.com <mailto:qutpeter at gmail.com> > :
>>> >
>>> > It should be some environmental issue.
>>> > I can successfully run the smoke test on Windows 8,
>>> >
>>> > And the JVM is:
>>> > java version "1.7.0_51"
>>> > Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
>>> > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03,
>>> mixed mode)
>>> >
>>> > Regards
>>> >
>>> >
>>> > On Mon, Oct 13, 2014 at 8:35 PM, Peter Cai <
>>> qutpeter at gmail.com <mailto:qutpeter at gmail.com> >
>>> > wrote:
>>> >
>>> >
>>> > OS: Linux dev-01 3.13.0-27-generic #50-Ubuntu SMP
>>> Thu May 15 18:06:16
>>> > UTC 2014 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu
>>> 14.04 desktop)
>>> >
>>> > JVM:
>>> > java version "1.7.0_51"
>>> > Java(TM) SE Runtime Environment (build 1.7.0_51-b13)
>>> > Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03,
>>> mixed mode)
>>> >
>>> > My guess is environmental issue as well. But can't
>>> find anything so
>>> > far.
>>> >
>>> > Regards,
>>> >
>>> > Peter
>>> >
>>> >
>>> > On Mon, Oct 13, 2014 at 8:29 PM, Tomaž Cerar <
>>> tomaz.cerar at gmail.com <mailto:tomaz.cerar at gmail.com>
>>> > > wrote:
>>> >
>>> > os? jvm? arch?
>>> >
>>> > looking at our nightly jobs whole testsuite passes
>>> on our CI with
>>> > JDK7 & 8 on windows and on linux.
>>> >
>>> > I am guessing it must be environmental issue.
>>> >
>>> >
>>> > On Mon, Oct 13, 2014 at 11:47 AM, Peter Cai <
>>> qutpeter at gmail.com <mailto:qutpeter at gmail.com> >
>>> > wrote:
>>> >
>>> > Hi,
>>> >
>>> > It looks like that the current HEAD of Wildfly will
>>> failed when
>>> > running smoke testing with the following information:
>>> >
>>> > Results :
>>> >
>>> > Failed tests:
>>> >
>>> ServerInModuleDeploymentTestCase.testDeploymentStreamApi:93->testDeployments:614
>>> > expected:<[c767c5d5e516f6e04ec69f5a0f8ccdc0d63e6fa5,
>>> > 342ae7aec9bff370e3de8704ed9642a718986e61]> but
>>> > was:<[342ae7aec9bff370e3de8704ed9642a718986e61]>
>>> >
>>> > Any cues?
>>> >
>>> > Regards,
>>> >
>>> > _______________________________________________
>>> > wildfly-dev mailing list
>>> > wildfly-dev at lists.jboss.org
>>> <mailto:wildfly-dev at lists.jboss.org>
>>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > wildfly-dev mailing list
>>> > wildfly-dev at lists.jboss.org
>>> <mailto:wildfly-dev at lists.jboss.org>
>>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> >
>>> > ________________ __________
>>> >
>>> >
>>> > Eduardo Sant'Ana da Silva - Dr.
>>> > Pesquisador / Consultor de TI
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > wildfly-dev mailing list
>>> > wildfly-dev at lists.jboss.org
>>> <mailto:wildfly-dev at lists.jboss.org>
>>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> <mailto:wildfly-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>>
>>> --
>>> __________________________
>>> Eduardo Sant'Ana da Silva - Dr.
>>> Pesquisador / Consultor de TI
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
More information about the wildfly-dev
mailing list