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.
OT: every test in this package needs to be moved to the wildfly-core
testsuite.
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(a)gmail.com
> <mailto:qutpeter@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(a)gmail.com
> <mailto:qutpeter@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(a)gmail.com <mailto:tomaz.cerar@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(a)redhat.com <mailto:ewertz@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(a)gmail.com
> <mailto:eduardo.santanadasilva@gmail.com>>
> > To: "Peter Cai" <qutpeter(a)gmail.com
> <mailto:qutpeter@gmail.com>>
> > Cc: wildfly-dev(a)lists.jboss.org
> <mailto:wildfly-dev@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(a)gmail.com <mailto:qutpeter@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(a)gmail.com <mailto:qutpeter@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(a)gmail.com <mailto:tomaz.cerar@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(a)gmail.com <mailto:qutpeter@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(a)lists.jboss.org
> <mailto:wildfly-dev@lists.jboss.org>
> >
https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> >
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev(a)lists.jboss.org
> <mailto:wildfly-dev@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(a)lists.jboss.org
> <mailto:wildfly-dev@lists.jboss.org>
> >
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> <mailto:wildfly-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev