Leave the transportConnector's uri property alone as the original value of tcp://0.0.0.0:61618; that's the IP for brokers to use when talking to each other, but doesn't play when they're finding out about one another.
The way this is supposed to work (follow along at https://github.com/apache/activemq/blob/master/activemq-client/src/main/java/org/apache/activemq/transport/discovery/multicast/MulticastDiscoveryAgent.java) is that in order to bind to the ethwe NIC, you would set the discoveryUri property to "multicast://default" (which would join 239.255.2.3:6155, see the constants at the top of that class) and you would set the mcNetworkInterface field to "ethwe" to tell the socket to bind to that particular NIC instead of the default one chosen by MulticastDiscoveryAgent.findNetworkInterface(). Unfortunately, there's no attribute in the XSD <http://activemq.apache.org/schema/core/activemq-core-5.15.1.xsd> that corresponds to the mcNetworkInterface property. You have some options (which are not necessarily mutually exclusive): 1. Submit an enhancement request in JIRA asking that the mcNetworkInterface field be mapped to an XSD attribute so you can set it via the config file. 2. Modify the ActiveMQ code to add an XSD attribute yourself, then compile the code and use that patched version of ActiveMQ. (If you do this, hopefully you'll contribute the change back so that we maintain the fix instead of you.) 3. Modify the ActiveMQ code to hard-code the mcNetworkInterface field (or some other local variable, however you choose to do it) to "ethwe", or to the value of a system property or environment variable of your choosing (to which you can then pass in "ethwe"), then compile the code and use that patched version of ActiveMQ. This is slightly easier to implement, but then you're stuck maintaining your patched version until someone else implements a permanent fix for the mainline ActiveMQ codebase. 4. Use some form of runtime bytecode manipulation to modify the value of the mcNetworkInterface field without modifying the ActiveMQ code. Maybe it would be possible to do this via AOP, or a mocking framework, or...? 5. In Eclipse, set a conditional breakpoint on MulticastDiscoveryAgent:279 whose condition is mcNetworkInterface="ethwe"; return false; and then attach your Eclipse debugger to each running broker process. This one is probably a non-starter in operations, but could very quickly and easily let you confirm that the fix in question will actually work before you implement option 2/3/4. Tim On Wed, Oct 18, 2017 at 9:30 AM, Jeroen van Ooststroom < j.van.ooststr...@gmail.com> wrote: > Hi all, > > I tried with the latest ActiveMQ 5.15.1 as well, but I unfortunately get > the > same result: it still won't do the automatic clustering, while locally > using > VMs this still works. > > Thanks, > Jeroen... > > > > -- > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User- > f2341805.html >
