[jboss-jira] [JBoss JIRA] (WFCORE-841) Patching module testsuite failure
Joe Wertz (JIRA)
issues at jboss.org
Mon Jul 27 09:48:02 EDT 2015
[ https://issues.jboss.org/browse/WFCORE-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093082#comment-13093082 ]
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)
More information about the jboss-jira
mailing list