NAT and WildFly 10 ActiveMQ
walkerca Jul 28, 2017 1:26 PMHi,
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