activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Bertram <>
Subject Re: Cluster/Federated Artemis problems
Date Mon, 25 Jan 2016 16:59:44 GMT
The documentation is pretty clear (IMO) about the purpose of the "address" property of the
cluster connection.  There's nothing "magic" about it.  In short, "Each cluster connection
only applies to addresses that match the specified address field. An address is matched on
the cluster connection when it begins with the string specified in this field."  The documentation
itself [1] includes a more thorough explanation (including a few simple examples), but I didn't
want to paste the whole thing here when you can simply go there and read it yourself.  

In your particular case, the value of "jms" works for you because you're ostensibly using
a JMS topic and all addresses for JMS topics are queues are prefixed with "jms.".  You can
read more about how JMS maps to the Artemis "core" API here [2].

If you could open a JIRA [3] regarding the datagram issue you observed and outline a way I
can observe that myself that would go a long way in making sure the issue is resolved.  Thanks!


[1] (see the "Configuring Cluster
Connections" section)

----- Original Message -----
From: "Lachezar Dobrev" <>
Sent: Monday, January 25, 2016 10:35:36 AM
Subject: Re: Cluster/Federated Artemis problems

  Your help is appreciated, and effective.

  I have misunderstood the configuration elements. I was not clear that the
acceptor and the connector describe the same end-point. After fixing that I
saw a few logging messages about bridges being built.
  The configuration help that you pointed me to showed an inexplicable (to
me) address for the cluster "jms".
  After putting this *magic* address the cluster is now up and running.

  Now I'm trying to implement the fixed-peer cluster. I'm having trouble
with that, but the progress is good.

  I still believe sending 4K datagrams is a bug though.

2016-01-25 17:02 GMT+02:00 Justin Bertram <>:

> I imagine this is just a configuration issue somewhere.  We ship lots of
> examples which use clustering (although not embedded), and the test-suite
> is full of embedded clustering tests.  As far as I know all these are
> working properly.
> When you say the NettyAcceptor and NettyConnector use a "random-high-port"
> are they both using the same port?  If not, that would be a problem.
> You can configure a cluster "statically" (i.e. without UDP discovery).
> Check out the "clustered-static-discovery" example and also see the
> documentation [1].
> I'd like to understand a bit more about how/why your current configuration
> is failing.  Could you provide a reproducible test-case?
> Lastly, I think you'd be best served by being on Artemis 1.2 which we
> recently released.
> Justin
> [1] (see the
> "Discovery using static Connectors" section)
> ----- Original Message -----
> From: "Lachezar Dobrev" <>
> To:
> Sent: Monday, January 25, 2016 5:22:16 AM
> Subject: Cluster/Federated Artemis problems
>   Hello group members.
>   I'm having problems with clustering/federating an application's Artemis
> embedded server.
>   The application is a .WAR with Springframework 4 and Embedded Artemis
> 1.1.0 (from Spring).
>   Multiple instances of the application are expected to be deployed in
> multiple spots. The Artemis component is expected to cluster a JMS Topic
> between nodes so that if any node sends a message on the topic all
> listeners on all nodes should receive the message.
>   With a few problems I was able to make the Embedded Artemis Server handle
> topic in a single deployment.
>   Every application connects to the Embedded Artemis using InVM connector.
>   Trying to cluster instances does not work!
>   My configuration contains:
>   - A NettyAcceptor  on (host):(random-high-port)
>   - A NettyConnector on (host):(random-high-port) named "cluster-connector"
>   - A BroadcastGroupConfiguration named "cluster-broadcast"
>     = UDPBroadcastEndpointFactory
>       * group-host
>       * group-port 12345
>       * local-host (host)
>       * local-port (random-high-port)
>     = ConnectorInfos
>       * "cluster-connector"
>   - DiscoveryGroupConfiguration named "cluster-discovery"
>     = UDPBroadcastEndpointFactory
>       * group-host
>       * group-port 12345
>       * local-host (host)
>       * local-port (random-high-port)
>   - ClusterConnectionConfiguration named "cluster"
>     = address: "cluster-address"
>     = connectorName: "cluster-connector"
>     = discoveryGroupName: "cluster-discovery"
>   The configuration is done in Java (not XML) via
> o.a.a.a.core.config.Configuration
>   As already noted this does not work, even worse when a second application
> instance is brought up the VMs on both instances hang on attempt to
> shut-down.
>   I noticed a possible problem: the network monitor showed, that the
> applications keep open UDP socket that has a Send-Q that continuously grows
> until about 200K pending, and then it seizes. Further using a tcpdump I
> noticed, that the packages being sent by Artemis look invalid, as they're
> really BIG: 4096 bytes broadcast datagrams!
>   Looking further I found out a possible BUG in
> …cluster.impl.BroadcastGroupImpl in the broadcastConnectors() method. It
> seems the method works incorrectly with the ActiveMQBuffer and the
> underlying NIO ByteBuffer, and instead of sending a package with the needed
> data it sends the whole Buffer of nearly 4K zeros and only a few hundred
> bytes of actual payload. A package of 4K is next to impossible to send as a
> datagram packet.
>   I've tried to perform a hot-fix for this issue and succeeded (the
> datagrams fell to about 250 bytes), datagrams are sent and received, but
> the cluster still does not form.
>   Please advise!
>   Is there a way to create a cluster without using discovery? Assuming I
> know every instance of the application at initialisation time is it
> possible to create a cluster of pre-defined nodes?
>   Hope I get help.

View raw message