[wildfly-dev] Outbound Socket host resolution

Jeff Mesnil jmesnil at redhat.com
Wed Feb 19 10:19:06 EST 2014


[changing the subject as HTTP upgrade is not part of the discussion]

On 19 Feb 2014, at 15:52, Brian Stansberry <brian.stansberry at redhat.com> wrote:

> The outbound-socket-binding config doesn't allow this to be configured 
> correctly, using the correct address?

Yes you’re right, I overlooked it.
 By convenience, the messaging subsystem allows to use a socket-binding to configure the connector but the correct way is to use an outbound-socket-binding (and it lets specify the host).
(I’ve closed WFLY-2963 as we don’t need it).

Since I am using port-forwarding around the openshift proxy issue, I configure the messaging connector with an outbound-socket to connect to 127.0.0.1 (that’s is then forwarded to the OpenShift server).
With that tweak, the quickstart works but it’s ugly.

However, I wonder if that’ll also work when we would not need to use port-forwarding.

In that case, I would just need to add an outbound-socket-binding with the DNS name of my app (helloworldjms2-jmesnil.rhcloud.com).
Looking at OutboundSocketBinding, its getDestinationAddress() method returns a /resolved/ InetAddress, not the name that’s set in the management model.
And the OpenShift server returns a different resolved IP address for this domain name than my local machine:

[openshift] helloworldjms2-jmesnil.rhcloud.com -> 10.235.52.32
[localhost] helloworldjms2-jmesnil.rhcloud.com -> 23.22.246.120

When my client on my local machine will try to connect to the server, it will use the 10.235.52.32 IP address that’s not reachable instead 23.22.246.120.

For my use case to work, I would need to get the “raw” destination address (whatever the user specified in the management model) and not let the server resolve the address (the address will be resolved by the client).
Is that a valid use case or am I missing something obvious?

jeff

-- 
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/




More information about the wildfly-dev mailing list