WildFly 10 in OpenShift - remote JMS client gets confused after initial JNDI lookup
hobbsjd Jul 7, 2016 9:39 AMI have two pods within the same OpenShift Enterprise project. One pod is an application hosted in WildFly 10, the other is a Camel application. In the Camel application, I establish an initial context and lookup the connection factory like so:
LOG.log(Level.INFO, "Initiating Artemis connection to " + host + " port " + port + " as " + user);
String url = "http-remoting://" + host + ":" + port;
Properties props = new Properties();
props.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
props.put(Context.PROVIDER_URL, url);
props.put(Context.SECURITY_PRINCIPAL, user);
props.put(Context.SECURITY_CREDENTIALS, pass);
context = new InitialContext(props);
ActiveMQConnectionFactory cf = (ActiveMQConnectionFactory) context.lookup("jms/RemoteConnectionFactory");
The initial context lookup succeeds and I have a connection factory. When I attempt to use it, I get a connection failure. Stepping thru the above code, I notice that the CF returned by the lookup has a different host name than what I used in the initial lookup. For example:
I asked for "portfolio.sdateam.svc.cluster.local" when setting up the initial context. The CF has a property set to "portfolio-60-ra5al:8080" which is the name of the pod running WildFly. DEBUG output from the camel pod:
2016-07-06 16:48:55.173 INFO [Routes] Initiating Artemis connection to portfolio.sdateam.svc.cluster.local port 8080 as camel
...
2016-07-06 16:49:00.269 DEBUG [org.apache.activemq.artemis.core.client] Started Netty Connector version 4.0.30.Final
349 2016-07-06 16:49:00.343 DEBUG [org.apache.activemq.artemis.core.client] Remote destination: portfolio-60-ra5al:8080
350 2016-07-06 16:49:00.359 FINE [io.netty.util.internal.ThreadLocalRandom] -Dio.netty.initialSeedUniquifier: 0x9772249a235cbd3d (took 0 ms)
351 2016-07-06 16:49:00.464 FINE [io.netty.buffer.ByteBufUtil] -Dio.netty.allocator.type: unpooled
352 2016-07-06 16:49:00.464 FINE [io.netty.buffer.ByteBufUtil] -Dio.netty.threadLocalDirectBufferSize: 65536
353 2016-07-06 16:49:00.574 ERROR [org.apache.activemq.artemis.core.client] AMQ214016: Failed to create netty connection
354 java.nio.channels.UnresolvedAddressException
It appears that during the lookup, something is using the hostname of the wildfly server instead of the hostname I asked for in the initial context.
Is there a way to control what value is returned for the host name when this lookup is performed?
Relevant portion of standalone-full.xml
<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
<server name="default">
<security-setting name="#">
<role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
</security-setting>
<address-setting name="#" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
<http-connector name="http-connector" endpoint="http-acceptor" socket-binding="http"/>
<http-connector name="http-connector-throughput" endpoint="http-acceptor-throughput" socket-binding="http">
<param name="batch-delay" value="50"/>
</http-connector>
<in-vm-connector name="in-vm" server-id="0"/>
<http-acceptor name="http-acceptor" http-listener="default"/>
<http-acceptor name="http-acceptor-throughput" http-listener="default">
<param name="batch-delay" value="50"/>
<param name="direct-deliver" value="false"/>
</http-acceptor>
<in-vm-acceptor name="in-vm" server-id="0"/>
<jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>
<jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>
<connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
<connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector"/>
<pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/>
</server>
</subsystem>