Bug 899899 (JBPAPP6-718)

Seems like Python script is not able to find uuid.

Just found existing issue in AS7...so are we expecting the fix by ER2?
https://issues.jboss.org/browse/AS7-3845

Link: Added: This issue is a dependency of AS7-3845

This was fixed upstream so EAP will get the fix for ER4.

Ondra, anything marked testsuite is getting automatically assigned to you 

Upstream fixes were merged with the latest rebase.

This testcase is still failing on windows with ER5 but with different exception:

Error Message

JDR Report has incorrect checksum expected:<[f3e1cc34764d5ee39c0e71aaf247fe63]> but was:<[b5da6113c90a3e9e953eb31394615c86]>

Stacktrace

org.junit.ComparisonFailure: JDR Report has incorrect checksum expected:<[f3e1cc34764d5ee39c0e71aaf247fe63]> but was:<[b5da6113c90a3e9e953eb31394615c86]>
	at org.junit.Assert.assertEquals(Assert.java:123)

http://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-60-as-testsuite-Windows-matrix-OracleJDK6/jdk=java16_default,label=Win2k8_x86_64/lastCompletedBuild/testReport/org.jboss.as.test.integration.jdr.mgmt/JdrReportManagmentTestCase/generateStandaloneJdrReport/

Shelly is this passing upstream?I just checked the latest run pointed in job in AS7-3845 
and it does not seem stable

http://hudson.jboss.org/hudson/view/All/job/JBoss-AS-7.1.x-testSuite-windows/

There was a problem with git checkout on windows from Hudson escalated here:
https://engineering.redhat.com/rt/Ticket/Display.html?id=147654

looks like there are still some issues. 

Have you tried to test the checksum outside of the test suite? I'd be interested to know what a tool like md5sum (or the equivalent on windows) outputs.

@Madmuhita,pls update with your test results against ER6.

Link: Added: This issue is a dependency of JBPAPP-8827

Link: Added: This issue is related to JBPAPP-7965

Link: Removed: This issue is a dependency of JBPAPP-8827 

This testcase fails currently(EAP6 ER6 cycle) not only on Windows but across all platforms with following stacktrace:

([("subsystem" => "jdr")]): java.lang.NullPointerException
	at org.jboss.as.jdr.SosInterpreter.getPythonScriptLocation(SosInterpreter.java:206) [jboss-as-jdr-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.jdr.SosInterpreter.collect(SosInterpreter.java:75) [jboss-as-jdr-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.jdr.SosInterpreter.collect(SosInterpreter.java:61) [jboss-as-jdr-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.jdr.JdrReportService.collect(JdrReportService.java:130) [jboss-as-jdr-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.jdr.JdrReportRequestHandler$1.execute(JdrReportRequestHandler.java:71) [jboss-as-jdr-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.jdr.JdrReportRequestHandler.execute(JdrReportRequestHandler.java:87) [jboss-as-jdr-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:466) [jboss-as-controller-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:385) [jboss-as-controller-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:272) [jboss-as-controller-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:200) [jboss-as-controller-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:121) [jboss-as-controller-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:287)
	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:487)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_24]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_24]
	at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_24]
	at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA-redhat-1.jar:2.0.0.GA-redhat-1]

This test is passing upstream:
https://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-7.1.x-testSuite-windows/1166/testReport/org.jboss.as.jdr/

Will verify it is passing prior to the EAP 6 ER7 hand off.

The problem in ER6 was related to the unsigning.  This is fixed now.

JdrReportManagmentTestCase fails with JDR Report has incorrect checksum expected <..> but was <..>
in attachment you can find report from my machine that where it fails

Attachment: Added: sosreport-THOR-20120507174154.zip
Attachment: Added: sosreport-THOR-20120507174154.zip.md5

JDR Report has incorrect checksum expected:<[a5f61f94cb7009eb92d1460d4e997bbc]> but was:<[ed9df33aec1c61abad027fdcf86a89fd]>

Attachment: Added: sosreport-THOR-20120507180121.zip
Attachment: Added: sosreport-THOR-20120507180121.zip.md5

manuly ran md5 sum:
windows native (md5sum, md5sums)= ed9df33aec1c61abad027fdcf86a89fd
jython 2.5.2 = a5f61f94cb7009eb92d1460d4e997bbc
python 2.7.2 = 48bb1228c142d9473df60242ecd500b9
java (commons-codec) = ed9df33aec1c61abad027fdcf86a89fd

python & jython have some strange results, given that windows native md5 sum (different apps) return same result that commons-codec does that would be proper result. test uses commons-codec to calculated and then compares it to what was stored in file by jython script

Can you paste the python/jython code used to calculate the sums too?

code used was:

{code}
import hashlib
fname= 'C:\\development\\jboss7-mine\\build\\target\\jboss-as-7.1.2.Final-SNAPSHOT\\standalone\\tmp\\sosreport-THOR-20120507180121.zip.md5'
hashlib.md5(file(fname, 'r').read()).hexdigest()
{code}

This is on my OS X box running python 2.7.1:

{code}
>>> fname = '/Users/jhjaggars/Downloads/sosreport-THOR-20120507180121.zip'
>>> hashlib.md5(file(fname, 'r').read()).hexdigest()

'ed9df33aec1c61abad027fdcf86a89fd'
{code}

This has some symptoms of a hashlib issue in python/jython. 

Just for reference, problem was with the way file was open, instead of 'r' for read it has to be 'rb' for read as binary.

This test continues to fail in EAP6 ER7 due to differences in checksum

http://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-60-as-testsuite-Windows-matrix-OracleJDK7/17/jdk=java17_default,label=Win2k8_x86/testReport/org.jboss.as.test.integration.jdr.mgmt/JdrReportManagmentTestCase/generateStandaloneJdrReport/

Link: Added: This issue is incorporated by JBPAPP-8860

Madhumita, this link is right for ER7 build, but code was fixed in upstream and is part of 7.1.2.final, can we rerun tests on latest ER8/CR1/GA code?

Tomaz,
     Please change the fix version for next release its marked for ER7.

Also please could you check JBPAPP-8860 and comment on that?currently I see 49 failures in the best run I could have on Windows in this cycle(ER7).....

This test should be fixed in ER8 on Windows.

This testcase now pass on Windows as verified with EAP6 ER8

https://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-60-as-testsuite-Windows-matrix-OracleJDK6/jdk=java16_default,label=Win2k8r2_x86_64/lastCompletedBuild/testReport/org.jboss.as.test.integration.jdr.mgmt/JdrReportManagmentTestCase/

Link: Added: This issue is related to JBPAPP-9073

Release Notes Docs Status: Added: Not Required

Release Notes Docs Status: Removed: Not Required 
Docs QE Status: Removed: NEW