8:48 a.m.
[
https://issues.jboss.org/browse/WFCORE-841?page=com.atlassian.jira.plugin...
]
Joe Wertz commented on WFCORE-841:
----------------------------------
I've ensured LocalPatchInfoPatchIdUnitTest is running first, and that only that one
and PatchInspectUnitTestCase are running so nothing is between them, but I can't
replicate it. I can't find a way the tests could interfere with each other either.
Patch Inspect only seems to read an XML in the patch, so I'm not sure how an
environment mess would effect it.
I can force this to happen in two ways.
1) Moving the bytestream reset below the ctx.handle at line 180. Which makes the entire
byte stream empty.
2) Adding a newline character to the bytestream before the ctx.handle at line 180. Which
messes up the output processing because no empty lines are expected.
But I can't figure out a race situation that could cause the first problem or where a
spare newline character would come from to cause the second.
Is it possible to get the size of the byte array at PatchInspectUnitTestCase line 180?
That would let me know if it's a newline or if the stream is empty. If it's a
newline the output processing can be tweaked to ignore them even if I'm not sure where
they're coming from.
Adding a short sleep between 179 and 180 would also test if this is a race condition of
some kind. Possibly the streams is not getting updated fast enough to be turned into a
byteArray and processed.
I've got a Fedora 22 and a Win7 environment, but haven't gotten it to show up on
either one. No OSX to experiment with though.
Patching module testsuite failure
---------------------------------
Key: WFCORE-841
URL: https://issues.jboss.org/browse/WFCORE-841
Project: WildFly Core
Issue Type: Bug
Components: Patching
Environment: $ java -version
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
OS X Yosemite 10.10.4
Reporter: Brian Stansberry
Assignee: Alexey Loubyansky
Fix For: 2.0.0.Alpha12
When running the core build locally , the 'patching' module testsuite fails:
{code}
-------------------------------------------------------
T E S T S
-------------------------------------------------------
objc[58076]: Class JavaLaunchHelper is implemented in both
/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/bin/java and
/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/jre/lib/libinstrument.dylib.
One of the two will be used. Which one is undefined.
Running org.jboss.as.patching.cli.ContentConflictsUnitTestCase
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.892 sec - in
org.jboss.as.patching.cli.ContentConflictsUnitTestCase
Running org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.269 sec - in
org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase
Running org.jboss.as.patching.cli.PatchInspectUnitTestCase
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.044 sec <<<
FAILURE! - in org.jboss.as.patching.cli.PatchInspectUnitTestCase
testMain(org.jboss.as.patching.cli.PatchInspectUnitTestCase) Time elapsed: 0.044 sec
<<< FAILURE!
java.lang.AssertionError: expected:<{Type=one-off, Description=this is one-off patch
1, Identity name=product, Identity version=version, Patch
ID=e7221af6-a05f-49f9-bf24-e40501b54db6, Link=http://test.one}> but was:<{}>
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.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:76)
at org.jboss.as.patching.cli.CLIPatchInfoUtil.assertPatchInfo(CLIPatchInfoUtil.java:57)
at
org.jboss.as.patching.cli.PatchInspectUnitTestCase.testMain(PatchInspectUnitTestCase.java:180)
{code}
If I clean and run the test by itself, it passes. It also passes on the CI jobs on
brontes, but the log shows the tests excecute in a different order.
Given all that, my expectation is that one of the two tests that run locally before the
failing one is leaving some sort of mess behind. I've found that @Ignoring
org.jboss.as.patching.cli.LocalPatchInfoPatchIdUnitTestCase solves the problem, so I will
send up a PR that does that as a workaround.
The problem does not occur with 2.0.0.Alpha11, and there are only two commits in master
since then. One is an undertow upgrade, so it's almost certain the problem was
introduced with the other: https://github.com/wildfly/wildfly-core/pull/904
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)