4:30 p.m.
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> 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.
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat