[wildfly-dev] Issue with HTTP upgrade for remote naming on OpenShift?

[Brian Stansberry]

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

I saw your WFLY-2963 patch and I can sort of imagine how it might help 
in some odd scenario, but it seems that if the messaging subsystem 
config could store the correct value, the outbound-socket-binding itself 
could store the correct value.

On 2/19/14, 2:15 AM, Jeff Mesnil wrote:
>
> On 18 Feb 2014, at 22:19, Farah Juma <fjuma at redhat.com> wrote:
>
>> I'm looking into this as well to see if there's a way to make this work. When using port forwarding, I'm finding that an error still occurs:
>
> At this stage, port forwarding works. Thanks Farah.
>
> The remaining issue is the way HornetQ configures its connectors.
>
> HornetQ connectors are the bits that are retrieved using JNDI and contains the informations to connect to the HornetQ server (embedded with WildFly in our case).
> The ugly ugly part of it is that the connector must know the host of the server to connect to.
> In WildFly, we resolve the socket-binding (http in this case) to get this address[1]. When using OpenShift, the HornetQ connectors will use the OpenShift server address (127.5.118.129).
> If I use port forwarding, the remote naming will work and I will retrieve a connector that wants to connect to 127.5.118.129 from my local machine and this does not work.
>
> The HornetQ team has some features planned for the cloud. I’ll let them know about this.
>
> [1] https://github.com/wildfly/wildfly/blob/master/messaging/src/main/java/org/jboss/as/messaging/HornetQService.java#L181
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat