Bug 809125 - [eap6] incorrectly detected server listening on IPv6 address
[eap6] incorrectly detected server listening on IPv6 address
Status: NEW
Product: RHQ Project
Classification: Other
Component: Plugins (Show other bugs)
4.4
Unspecified Unspecified
high Severity unspecified (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
:
Depends On: 822218
Blocks: 919199 as7-plugin
  Show dependency treegraph
 
Reported: 2012-04-02 10:35 EDT by Libor Zoubek
Modified: 2015-11-01 19:45 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Libor Zoubek 2012-04-02 10:35:19 EDT
Description of problem: I have setup EAP6 to listen on IPv6 address ::1 (which should be similar to 127.0.0.1 in IPv4 world), RHQ detects it, but after import, server appears offline


Version-Release number of selected component (if applicable):
Version: 4.4.0-SNAPSHOT
Build Number: f537827
EAP6 Beta1

How reproducible:always


Steps to Reproduce:
1.setup EAP6 to run in standalone mode and listen on IPv6 ::1 address
a) edit standalone/configuration/standalone.xml and set${jboss.bind.address.management:::1} and ${jboss.bind.address:::1}
2. start using ./standalone.sh -Djava.net.preferIPv4Stack=false -b::1 -bmanagement::1
a)./standalone.sh -Djava.net.preferIPv4Stack=false
3. discover EAP by agent, import it
  
Actual results: such EAP is disovered, but after import it appears offline - no children are discovered, connection settings are set correctly.


Expected results: EAP is discovered and correctly imported


Additional info:I have tried to make EAP listening on :: (which is similar to 0.0.0.0 in IPv4 world) and in this setup this issue is not reproducible.
Comment 1 Mike Foley 2012-04-02 11:32:45 EDT
per BZ triage 4/2/2012 HIGH
Comment 2 Charles Crouch 2012-04-12 20:23:17 EDT
Lowering priority, this is not a blocker for rhq4.4
Comment 3 Heiko W. Rupp 2012-05-15 05:57:44 EDT
HTTPUrlConnection.getOutputStream() returns "java.net.SocketException: Protocol family unavailable"

The url looks correct as "http://[::1]:9990/management" and from the browser I can use it to access the as7 management  classes.

Actually it looks like we may hit this sun bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6914801 
  " The JDK requires all sockets be IPv4 or all sockets be IPv6. It doesn't support the scenario where some Sockets are IPv4 and others are IPv6 "

Meaning that if anything in the agent talks IPv4, we can not talk IPv6 to as7.

The above can easily be verified:

- start as7 with -bmanagement=::1
- start the standalone container with the as7 plugin and no debugger attachment defined. Discover servers, request availability -> works . Stop standalone container

- set env to 
export RHQ_AGENT_JAVA_OPTS="-Xmx320m -Djava.net.preferIPv4Stack=true -agentlib:jdwp=transport=dt_socket,address=8788,server=y,suspend=n"
 
 - start the standalone container with the as7 plugin and no debugger attachment defined. Discover servers, request availability -> does not work, as the IPv4 socket on port 8788 is already open
Comment 4 Jan Martiska 2012-05-16 04:34:52 EDT
Please try a workaround - tell the agent to communicate with jon server on a ipv4-mapped ipv6 address, eg. ::ffff:127.0.0.1, this might not prevent agent from further creation of ipv6 sockets
Comment 5 Lukas Krejci 2012-05-21 04:59:41 EDT
From the Java documentation (http://docs.oracle.com/javase/6/docs/technotes/guides/net/properties.html):

java.net.preferIPv4Stack (default: false)
    If IPv6 is available on the operating system the underlying native socket will be an IPv6 socket. This allows Java(tm) applications to connect too, and accept connections from, both IPv4 and IPv6 hosts.

    If an application has a preference to only use IPv4 sockets then this property can be set to true. The implication is that the application will not be able to communicate with IPv6 hosts.


I'm setting this to be blocked by bug 822218 which suggests dropping that property from the agent's commandline.

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