Bug 900361 (JBPAPP6-955) - Tests in EAP testsuite fail on IBM JDK due to Exception thrown in JGroups Subsystem
Summary: Tests in EAP testsuite fail on IBM JDK due to Exception thrown in JGroups Sub...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: JBPAPP6-955
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Testsuite
Version: 6.0.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: EAP 6.0.1
Assignee: Richard Achmatowicz
QA Contact:
URL: http://jira.jboss.org/jira/browse/JBP...
Whiteboard:
Depends On:
Blocks: JBPAPP6-1159
TreeView+ depends on / blocked
 
Reported: 2012-05-03 20:54 UTC by Madhumita Sadhukhan
Modified: 2014-06-28 12:34 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-10-04 13:46:07 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
standalone_IBM.xml (15.10 KB, text/xml)
2012-05-16 14:26 UTC, Madhumita Sadhukhan
no flags Details
standalone_SUN.xml (15.10 KB, text/xml)
2012-05-16 14:26 UTC, Madhumita Sadhukhan
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker JBPAPP6-955 0 Major Closed Tests in EAP testsuite fail on IBM JDK due to Exception thrown in JGroups Subsystem 2013-10-01 09:58:44 UTC

Description Madhumita Sadhukhan 2012-05-03 20:54:42 UTC
project_key: JBPAPP6

Most of the clustering tests for eg. JSFFailoverTestCase fail with following stacktrace:--

Error Message

Could not deploy to container: "JBAS014750: Operation handler failed to complete"

Stacktrace

org.jboss.arquillian.container.spi.client.container.DeploymentException: Could not deploy to container: "JBAS014750: Operation handler failed to complete"
	at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:74)
..............................................................................................
.............................................................................................................


Failed to start service jboss.jgroups.channel.web: org.jboss.msc.service.StartException in service jboss.jgroups.channel.web: java.lang.IllegalArgumentException: diagnostics_addr / diagnostics_port and mcast_addr / mcast_port have to be different
	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:62) [jboss-as-clustering-common-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:897) [rt.jar:1.6.0]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919) [rt.jar:1.6.0]
	at java.lang.Thread.run(Thread.java:736) [vm.jar:1.6.0]
Caused by: java.lang.IllegalArgumentException: diagnostics_addr / diagnostics_port and mcast_addr / mcast_port have to be different
	at org.jgroups.protocols.UDP.createSockets(UDP.java:359) [jgroups-3.0.9.Final-redhat-0-todo.jar:3.0.9.Final]
	at org.jgroups.protocols.UDP.start(UDP.java:224) [jgroups-3.0.9.Final-redhat-0-todo.jar:3.0.9.Final]
	at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:938) [jgroups-3.0.9.Final-redhat-0-todo.jar:3.0.9.Final]
	at org.jgroups.JChannel.startStack(JChannel.java:841) [jgroups-3.0.9.Final-redhat-0-todo.jar:3.0.9.Final]
	at org.jgroups.JChannel.connect(JChannel.java:277) [jgroups-3.0.9.Final-redhat-0-todo.jar:3.0.9.Final]
	at org.jgroups.JChannel.connect(JChannel.java:261) [jgroups-3.0.9.Final-redhat-0-todo.jar:3.0.9.Final]
	at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:44) [jboss-as-clustering-jgroups-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:59) [jboss-as-clustering-common-7.1.1.Final-redhat-1.jar:7.1.1.Final-redhat-1]
	... 3 more

Comment 1 Rajesh Rajasekaran 2012-05-03 21:02:39 UTC
Madhumita, I don't think this is related to IBM JDK. See AS7-4540. Can you try the workaround? The diagnostics addr can be some default value, it doesn't have to be unique across hudson jobs, you can use $MCAST_ADDR for the other multicast address for the testsuite run on hudson

Comment 2 Madhumita Sadhukhan 2012-05-03 21:11:52 UTC
Rajesh,

       Yes I am aware of AS7-4540 and I am already using workaround $MCAST_ADDR to run this job on IBM JDK.Infact with this workaround the tests do pass on SUN JDK.Probably the IBM JDK behaves differently while setting these values ...hence i have kept this assigned to myself to investigate further.

http://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-60-as-testsuite-RHEL6-zipbuiltonoracleJDK6_testrunIBMJDK16/configure

Comment 3 Madhumita Sadhukhan 2012-05-15 10:35:24 UTC
Assuming that the IBM JDK was behaving differently and not picking up the proper jgroups and mcast which has been currently handled in testsuite pom(workaround suggested in AS7-4540),I tried to set then from commandline:

mvn -fae -B -s settings.xml install -Pnormal -DallTests -Dmaven.test.failure.ignore=true -Dmaven.repo.local=local-repo -Djboss.dist=${WORKSPACE}/jboss-eap-6.0 -Dsurefire.forked.process.timeout=3800 -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -Dmcast=$MCAST_ADDR -Dmcast.jgroupsDiag=224.0.75.75 -Dmcast.modcluster=224.0.1.105 

However this did not help and I still see the same error diagnostics_addr / diagnostics_port and mcast_addr / mcast_port have to be different.

It is surprising why this problem occurs only on IBM JDK as workaround suggested in AS7-4540 does not seem to work for IBM JDK

http://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-60-as-testsuite-RHEL6-buildIBMJDK6_testrunIBMJDK16/62/testReport/org.jboss.as.test.clustering.cluster.ejb3/StatefulTimeoutTestCase%28UDP%29/testStatefulTimeout/

Ondra, do you have an explanation for these failures and do you think fix for JBPAPP-8400 will fix this?

Comment 4 Madhumita Sadhukhan 2012-05-16 14:26:12 UTC
Attachment: Added: standalone_IBM.xml
Attachment: Added: standalone_SUN.xml


Comment 5 Madhumita Sadhukhan 2012-05-16 14:27:42 UTC
Ondra,

        As discussed I have attached the standalone.xml files taken from testsuite/integration/clust/target... 
I have also generated a diff which shows as follows:

269c269
<             <wsdl-host>${jboss.bind.address:10.16.95.134}</wsdl-host>
---
>             <wsdl-host>${jboss.bind.address:10.16.94.118}</wsdl-host>

281c281
<             <inet-address value="10.16.95.134"/>
---
>             <inet-address value="10.16.94.118"/>

284c284
<             <inet-address value="${jboss.bind.address:10.16.95.134}"/>
---
>             <inet-address value="${jboss.bind.address:10.16.94.118}"/>

292c292
<             <inet-address value="${jboss.bind.address.unsecure:10.16.95.134}"/>
---
>             <inet-address value="${jboss.bind.address.unsecure:10.16.94.118}"/>

307c307
<             <remote-destination host="10.16.95.134" port="25"/>
---
>             <remote-destination host="10.16.94.118" port="25"/>

Comment 6 Madhumita Sadhukhan 2012-05-16 14:33:23 UTC
Command on sunJDK:

mvn -B -X -s settings.xml clean install -Pnormal -Ppublic-repositories -Ppublic-plugin-repositories -Dmaven.test.failure.ignore=true -Dsurefire.test.failure.ignore=true -Dmaven.repo.local=local-repo -Djboss.dist=/mnt/hudson_workspace/workspace/eap-60-as-testsuite-RHEL6-oracleJDK6_smoke_with_distproperty-with-gitrepo-IPV4/jboss-eap-6.0 -Dskip-download-sources -fae -DallTests -Dnode0=10.16.95.134 -Dnode1=10.16.95.135 -Dmcast=227.43.88.174 -Dsurefire.forked.process.timeout=1800

Command on IBM JDK:

+ mvn -fae -B -s settings.xml install -Pnormal -DallTests -Dmaven.test.failure.ignore=true -Dmaven.repo.local=local-repo -Djboss.dist=/mnt/hudson_workspace/workspace/eap-60-as-testsuite-RHEL6-buildIBMJDK6_testrunIBMJDK16/jboss-eap-6.0 -Dsurefire.forked.process.timeout=3800 -Dnode0=10.16.94.118 -Dnode1=10.16.94.119 -Dmcast=227.43.88.216 -Dmcast.jgroupsDiag=224.0.75.75 -Dmcast.modcluster=224.0.1.105


Comment 7 Ondřej Žižka 2012-05-21 13:40:54 UTC
Those IPs are just different QA lab IPs.
Which shows that the harness works fine; seems like JGroups, or rather clustering module, has an IBM-JDK-specific bug in property processing.

Comment 8 Ondřej Žižka 2012-05-21 14:43:58 UTC
Bela Ban is on wacation.
Assigned to Matej Briskar. (He doesn't have JBPAPP privileges yet.)
He will try to find where the value get's lost.

Comment 9 Rajesh Rajasekaran 2012-05-21 14:59:29 UTC
Richard, would you be able to help debug this issue with IBM JDK?

Comment 10 Rajesh Rajasekaran 2012-06-06 23:02:05 UTC
Link: Added: This issue is a dependency of JBPAPP-9188


Comment 11 Richard Achmatowicz 2012-07-26 15:08:15 UTC
OK, i'll look at it.



Comment 12 Madhumita Sadhukhan 2012-07-27 11:32:59 UTC
These tests seem to pass in CR1(Not sure if its because there was some fix after Beta2 or it worked because I increased timeout substantially.
I set -Dsurefire.forked.process.timeout=3800)


http://hudson.qa.jboss.com/hudson/view/EAP6/view/EAP6-AS-Testsuite/job/eap-60-as-testsuite-RHEL6-buildIBMJDK6_testrunIBMJDK16/70/testReport/

Comment 14 Anne-Louise Tangring 2012-11-13 20:07:54 UTC
Docs QE Status: Removed: NEW 



Note You need to log in before you can comment on or make changes to this bug.