activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ulrich (JIRA)" <j...@apache.org>
Subject [jira] [Created] (AMQ-5516) Misbehaving name resolution in org.apache.activemq.transport.tcp.TcpTransportServer
Date Tue, 13 Jan 2015 09:17:34 GMT
ulrich created AMQ-5516:
---------------------------

             Summary: Misbehaving name resolution in org.apache.activemq.transport.tcp.TcpTransportServer
                 Key: AMQ-5516
                 URL: https://issues.apache.org/jira/browse/AMQ-5516
             Project: ActiveMQ
          Issue Type: Bug
          Components: Connector
    Affects Versions: 5.10.0
         Environment: AMQ  : 5.10.0
java : Oracle 1.7.0_72-b14
OS   : debian 7.4
            Reporter: ulrich
            Priority: Minor


Hi,

Here is the fragement of our spring config which declares the connectors:

<amq:networkConnectors>
	<amq:networkConnector name="brokerName" uri="multicast://default" />
</amq:networkConnectors>
<amq:transportConnector name="openwire" uri="tcp://10.1.1.5:61616" discoveryUri="multicast://default">
	<amq:publishedAddressPolicy>
		<amq:publishedAddressPolicy publishedHostStrategy="IPADDRESS" />
	</amq:publishedAddressPolicy>
</amq:transportConnector>
 

We have a configuration where several IP addresses are given to the machine in /etc/hosts.
There is no dns resolving mybox.
The relevant part is this one:

127.0.0.1 mybox localhost
10.1.1.5  mybox
172.16.2.5  mybox
#...others...


In org.apache.activemq.transport.tcp.TcpTransportServer:138, the method bind() calls resolveHostName(serverSocket,
addr) to rewrite the URI (why??).
The URI tcp://10.1.1.5:61616 is rewritten tcp://mybox:61616.

We can't advertise tcp://mybox:61616 since there is no name resolution. This is why the publishedAddressPolicy
is set to IPADDRESS. 
The multicast agent rewrites the URI again but the name resolution found for mybox is 127.0.0.1.
The advertised URI is now tcp://127.0.0.1:61616. Each broker tries to connect to themselves.

Depending on the order of the lines in /etc/hosts to resolve to the correct ip is about random
chance.
Is this call to resolveHostName(serverSocket, addr) really necessary? Why trying to outsmart
the configuration?





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message