NAT and WildFly 10 ActiveMQ

[walkerca]

Hi,

I have a WildFly 10 server that's working for EJB3 remoting and RESTful web services, but I'm having a problem with ActiveMQ.  It seems like ActiveMQ is handing back an IP address based on the network interface card rather than the -Djboss.bind.address setting.  This is a problem because the IP address is not known to the client.  Is there something I can put in my standalone-full.xml or in my client-side properties?

Here's my messaging-activemq config

<http-connector name="http-connector" socket-binding="https" endpoint="http-acceptor">

<param name="ssl-enabled" value="true"/>

</http-connector>

                <http-connector name="http-connector-throughput" socket-binding="https" endpoint="http-acceptor-throughput">

                    <param name="batch-delay" value="50"/>

<param name="ssl-enabled" value="true"/>

                </http-connector>

                <http-acceptor name="http-acceptor" http-listener="default-https"/>

                <http-acceptor name="http-acceptor-throughput" http-listener="default-https">

                    <param name="batch-delay" value="50"/>

                    <param name="direct-deliver" value="false"/>

                </http-acceptor>

This is my undertow config.  ApplicationRealm has a server-identities section that is working for https-remoting.

                <https-listener name="default-https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/>

This is my socket-binding group.

        <socket-binding name="https" port="${jboss.https.port:9443}" />

On the client side, I'm using the following which succeeds on the https-remoting calls for JMS objects.

        final Properties jndiProperties = new Properties();

        jndiProperties.put(Context.INITIAL_CONTEXT_FACTORY,

                           "org.jboss.naming.remote.client.InitialContextFactory");

        jndiProperties.put("jboss.naming.client.connect.options.org.xnio.Options.SASL_POLICY_NOPLAINTEXT", "false");

        jndiProperties.put(Context.PROVIDER_URL, url);

        jndiProperties.put(Context.SECURITY_PRINCIPAL, username);

        jndiProperties.put(Context.SECURITY_CREDENTIALS, password);

If I tweak the network configuration, I can get this to work.  I tried a few things related to the socket-bindings and client-mappings, but none seemed to have an effect.

Thank you,

Carl

[mnovak]

Hi Carl,

what error do you get? What is the ip address to which server is bound?

I guess you're trying to make lookup for "jms/RemoteConnectionFactory" which by default is using "http-connector". http-connector is using "https" socket binding which is pointing to jboss.bind.address and port 9443.

If your server is bound (jboss.bind.address) to IP address 0.0.0.0 then Artemis uses servers hostname in connector instead of 0.0.0.0. If client looks up this RemoteConnectionFactory and fails to resolve this hostname then creating connection fails.

If you have different problem then I think more info is needed.

Thanks,

Mirek

[walkerca]

The server is bound to a name, say jboss.example.com.  My EJB remoting over https is working fine as are RESTful web services and the JMS https-remoting lookups.  The problem I have is when I try to use the JMS objects, I get an error because my client code gets an IP address (not known to the client) rather than the hostname.  If I had to guess, I'd say the ActiveMQ code was returning a getInetAddresses() element rather than the -Djboss.bind.address.

[mnovak]

Resolving seems to be done by Wilfly10 Artemis integration layer in org.wildfly.extension.messaging.activemq.ActiveMQServerService:

host = NetworkUtils.canonize(sa.getAddress().getHostAddress());

I don't see into details here, not sure if it's intentional or not. Do you know why your client does not see IP address provided by server?

[walkerca]

I found an EAP 7 document and was able to resolve this by setting an outbound binding in a socket group.

<outbound-socket-binding name="jms-local">
  <remote-destination host="jms.example.org" port="8443"/>
  </outbound-socket-binding>

I spent some time with the code, specifically the WildFly / Artemis classes in the WildFly repo.  I guess if you don't specify a host with remote-destination, the implementation is free to determine the host IP.  This isn't a problem in most cases where the public address is the one used on the server.  In my case, there were network restrictions.

[mnovak]

Nice catch! There is always something new to learn :-)