activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Mack (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (AMQ-5516) Misbehaving name resolution in org.apache.activemq.transport.tcp.TcpTransportServer
Date Tue, 11 Apr 2017 07:21:41 GMT

    [ https://issues.apache.org/jira/browse/AMQ-5516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963899#comment-15963899
] 

Daniel Mack edited comment on AMQ-5516 at 4/11/17 7:21 AM:
-----------------------------------------------------------

confirmed for AMQ 5.14.3

possible workaround (Java Broker config) :

{code}
private DiscoveryAgent agent;
private TransportConnector transportConnector;

//(...)

private final void initialize() {
   //(...)
   if (null != agent) {
     agent.stop();
   }
   agent = MulticastDiscoveryAgentFactory.createDiscoveryAgent(URI.create("YOUR_MULTICAST_URI_HERE"));
   agent.registerService(transportConnector.getUri().toString());
   transportConnector.setDiscoveryAgent(agent);
   //(...)
}

public final void start() {
   //(...) !!! IMPORTANT, START YOUR BROKER / BROKERSERVICE HERE !!!
   agent.stop();
   agent.registerService(transportConnector.getUri().toString());
   agent.start();
}
{code}

similar workarounds could be applied to many other types of network configurations - simply
re-start your connectors with numeric addresses *after* the broker has already been started


was (Author: dma2017):
confirmed for AMQ 5.14.3

possible workaround (Java Broker config) :

{code}
private DiscoveryAgent agent;
private TransportConnector transportConnector;

//(...)

private final void initialize() {
   //(...)
   if (null != agent) {
     agent.stop();
   }
   agent = MulticastDiscoveryAgentFactory.createDiscoveryAgent(URI.create("YOUR_MULTICAST_URI_HERE"));
   agent.registerService("YOUR_NUMERIC_TRANSPORT_CONNECTOR_URI_HERE");
   transportConnector.setDiscoveryAgent(agent);
   //(...)
}

public final void start() {
   //(...) !!! IMPORTANT, START YOUR BROKER / BROKERSERVICE HERE !!!
   agent.stop();
   agent.registerService(transportConnector.getUri().toString());
   agent.start();
}
{code}

similar workarounds could be applied to many other types of network configurations - simply
re-start your connectors with numeric addresses *after* the broker has already been started

> 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.15#6346)

Mime
View raw message