activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <tb...@alumni.duke.edu>
Subject Re: Clustering ActiveMQ in an Amazon ECS/Docker/Weave environment
Date Thu, 19 Oct 2017 05:45:35 GMT
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.ooststroom@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message