Bug 1128087 - DomainDeploymentOverlayTestCase fails on OracleJDK1.8 pureIPV6 due to 'Unable to determine IP address from host name 2620:52:0:105f::ffff:8%eth0'
Summary: DomainDeploymentOverlayTestCase fails on OracleJDK1.8 pureIPV6 due to 'Unable...
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Domain Management, Testsuite
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: EAP 6.4.0
Assignee: Brian Stansberry
QA Contact: Petr Kremensky
Russell Dickenson
Depends On:
Blocks: java8
TreeView+ depends on / blocked
Reported: 2014-08-08 09:31 UTC by Pavel Jelinek
Modified: 2014-11-05 09:02 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-11-05 09:02:31 UTC
Type: Bug

Attachments (Terms of Use)

Description Pavel Jelinek 2014-08-08 09:31:24 UTC
Part of output when running org.jboss.as.test.integration.common.HttpRequest.execute(HttpRequest.java:59)
at org.jboss.as.test.integration.common.HttpRequest.get(HttpRequest.java:80)
at org.jboss.as.test.integration.domain.management.cli.DomainDeploymentOverlayTestCase.performHttpCall(DomainDeploymentOverlayTestCase.java:367)
at org.jboss.as.test.integration.domain.management.cli.DomainDeploymentOverlayTestCase.testSimpleOverrideWithRedeployAffected(DomainDeploymentOverlayTestCase.java:201): 

'The following error was encountered while trying to retrieve the URL: http://2620:52:0:105f::ffff:8%eth0:8080/deployment0/SimpleServlet? 
Unable to determine IP address from host name <q>2620:52:0:105f::ffff:8%eth0
The DNS server returned:
Name Error: The domain name does not exist.
This means that the cache was not able to resolve the hostname presented in the URL.' 

See: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-as-testsuite-RHEL-matrix-OracleJDK8-pureIPV6/3/jdk=jdk1.8,label_exp=RHEL6-ipv6%26%26x86_64%26%26pure-ipv6/testReport/org.jboss.as.test.integration.domain.management.cli/DomainDeploymentOverlayTestCase/testSimpleOverrideWithRedeployAffected/

Comment 1 Brian Stansberry 2014-08-14 21:17:01 UTC
Please provide the parameters used to launch the testsuite. I can't figure out what that test job is doing from clicking around for a couple minutes.

I doubt it's doing anything mysterious; I just want to know exactly what.

For example, our IPv6 jobs on lightning pass the following to maven:

-DallTests -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dorg.jboss.model.test.cache.strict=true -Dipv6 -Dnode0=::1 -Dnode1=::1 -DudpGroup=ff01::1

Comment 2 Pavel Jelinek 2014-08-19 08:44:04 UTC
I use e.g. (depending on particular slave IP configuration) -DallTests -Dmaven.test.failure.ignore=true -Dipv6 -Dnode0=2620:52:0:105f::ffff:8 -Dnode1=2620:52:0:105f::ffff:9 -Dmcast=ff0e:52:0:105f:5054:ff:fe84:c43a -fae -DproxySet=true -DproxyHost=proxy-01-ipv6.mw.lab.eng.bos.redhat.com -DproxyPort=3128 '-DnonProxyHosts=localhost|127.*|[::0]|[::1]|[2620:52:0:105f::ffff:9]|[2620:52:0:105f::ffff:8]' '-Dhttp.nonProxyHosts=localhost|127.*|[::0]|[::1]|[2620:52:0:105f::ffff:9]|[2620:52:0:105f::ffff:8]'

The main difference is in node0 and node1 args, I don't use ::1. I believe using adresses different from each other and from localhost is better.

Better link for example result is: 

Comment 4 Brian Stansberry 2014-08-26 15:18:17 UTC
What happens here is the test is passing an IPv6 zone id as part of the value of the 'host' param to the URI constructor. My guess is that is leading to the DNS problem.

I'm not sure what the exact problem is though.

There's a proposed RFC around that that describes how any such zone id should be URL escaped:


e.g. in ::1%lo the '%' needs to be escaped. We're not doing that.

I don't know if escaping that would fix the problem or whether the problem is the presence of the zone id altogether. It's also possible it has nothing to do with the zone id, but I doubt that.

Comment 5 Chao Wang 2014-10-13 07:21:26 UTC
I have tried to read the "host" value with both JDK7(1.7.0_67) and JDK8 (1.8.0_20). As per previous comment, it will return different values once ipv6 is configured:

[domain@[::1]:9999 /] /host=master/server=server-one/socket-binding-group=full-sockets/socket-binding=http:read-attribute(name=bound-address)
    "outcome" => "success",
    "result" => "::1%1"

[domain@[::1]:9999 /] /host=master/server=server-one/socket-binding-group=full-sockets/socket-binding=http:read-attribute(name=bound-address)
    "outcome" => "success",
    "result" => "::1%lo"

In upstream WFLY master, for both cases, '%' is escaped as the return value is:
[domain@[::1]:9990 /] /host=master/server=server-one/socket-binding-group=full-sockets/socket-binding=http:read-attribute(name=bound-address)
    "outcome" => "success",
    "result" => "::1"

commit in https://github.com/wildfly/wildfly/pull/4706 makes this result for any loopback address, and eliminates '%lo', '%eth0'. But I'm not certain why the result varies in different JDK versions.

Comment 6 Dominik Pospisil 2014-10-16 14:00:31 UTC
Is this still an issue? I am unable to reproduce it using Oracle JDK 1.8.0_20-b26 and current 6.x branch.

Comment 7 Dominik Pospisil 2014-10-16 14:25:43 UTC
Just noticed that the error comes from the proxy server. So my understanding is that the issue is that the request go through the proxy even if it is not supposed to.

Comment 8 Dominik Pospisil 2014-10-16 14:33:29 UTC
Is not the issuejust that the non-proxy host properties are not set up properly to match addresses containing zone id?

Comment 11 Petr Kremensky 2014-11-05 09:02:31 UTC
You're right, I don't see it with current configuration.


Thanks for assistance, closing as not_a_bug.

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