Re: [wildfly-dev] Outbound Socket host resolution

On 2/19/14, 9:19 AM, Jeff Mesnil wrote: > [changing the subject as HTTP upgrade is not part of the discussion] > > On 19 Feb 2014, at 15:52, Brian Stansberry <brian.stansberry(a)redhat.com&gt; 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? > I think OutboundSocketBinding needs to add a getter for the unresolvedDestinationAddress string. Which getter a caller uses would depend on their use case; i.e. whether they want a locally resolved address. There are some uses that AFAIK are purely internal, e.g. org.jboss.as.clustering.infinispan.subsystem.CacheAdd, so we shouldn't abandon the resolved address getter. Plus that would be an incompatible change. I propose adding OutboundSocketBinding.getUnresolvedDestinationAddress(), deprecating the current getDestinationAddress() and adding a new getResolvedDestinationAddress(). The latter is just a clearer name for the same function.