[
https://issues.jboss.org/browse/WFLY-4769?page=com.atlassian.jira.plugin....
]
George Turner commented on WFLY-4769:
-------------------------------------
No, it doesn't. My settings are bound to the host IP, not the 127.0.0.1. And the
issue is that when a connection factory lookup occurs across a NAT firewall, it give back
the address of the machine, NOT the address used on the client side of the firewall, thus
the lookup of the JNDI topic name fails. We have a workaround where we modify the
connection factory host value. But I have seen several example of setting up the
TransportConfiguration BEFORE making the lookup calls, so that the CF comes back with the
correct host value, instead of us doing it in code with our workaround.
WildFly 8 and 9. Connecting to topic using http-remoting and JNDI
fails when server is behind NAT firewall
-----------------------------------------------------------------------------------------------------------
Key: WFLY-4769
URL:
https://issues.jboss.org/browse/WFLY-4769
Project: WildFly
Issue Type: Bug
Components: JMS
Affects Versions: 8.2.0.Final, 9.0.0.CR1, 10.0.0.Final
Environment: RedHat7
Reporter: George Turner
Assignee: Jeff Mesnil
Server is behind NAT firewall. Client code:
Properties topicProperties = new Properties();
topicProperties.put(Context.INITIAL_CONTEXT_FACTORY,
"org.jboss.naming.remote.client.InitialContextFactory");
topicProperties.put(Context.PROVIDER_URL, "http-remoting://" + host +
":" + port);
InitialContext ctx = new InitialContext(topicProperties);
ConnectionFactory tmp = (ConnectionFactory)
topicCtx.lookup("jms/RemoteConnectionFactory");
connection = tmp.createConnection();
Jun 11, 2015 8:26:07 AM org.xnio.Xnio <clinit>
INFO: XNIO version 3.3.1.Final
Jun 11, 2015 8:26:07 AM org.xnio.nio.NioXnio <clinit>
INFO: XNIO NIO Implementation Version 3.3.1.Final
Jun 11, 2015 8:26:07 AM org.jboss.remoting3.EndpointImpl <clinit>
INFO: JBoss Remoting version 4.0.9.Final
javax.jms.JMSException: Failed to create session factory
at
org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:673)
at
org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:112)
at
org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:107)
at
com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.<init>(TestMessageConsumer.java:36)
at
com.lmco.spacefence.netcentric.test.client.TestMessageConsumer.main(TestMessageConsumer.java:24)
Caused by: HornetQNotConnectedException[errorType=NOT_CONNECTED message=HQ119007: Cannot
connect to server(s). Tried with all available servers.]
at
org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:905)
at
org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:669)
... 4 more
Disconnected from the target VM, address: '127.0.0.1:54275', transport:
'socket'
Client debugger shows the ConnectionFactory instance returned:
initialConnectors = {org.hornetq.api.core.TransportConfiguration[1]@2183}
0 = {org.hornetq.api.core.TransportConfiguration@2196}
"TransportConfiguration(name=http-connector,
factory=org-hornetq-core-remoting-impl-netty-NettyConnectorFactory)
?port=8080&host=10-10-20-77&http-upgrade-enabled=true&http-upgrade-endpoint=http-acceptor"
name = {java.lang.String@2198} "http-connector"
factoryClassName = {java.lang.String@2199}
"org.hornetq.core.remoting.impl.netty.NettyConnectorFactory"
params = {java.util.HashMap@2200} size = 4
0 = {java.util.HashMap$Node@2203} "port" -> "8080"
1 = {java.util.HashMap$Node@2204} "host" -> "10.10.20.77"
2 = {java.util.HashMap$Node@2205} "http-upgrade-enabled" ->
"true"
3 = {java.util.HashMap$Node@2206} "http-upgrade-endpoint" ->
"http-acceptor"
10.10.20.77 is IP address of server behind firewall, NOT the IP address used by the
client.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)