activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lachezar Dobrev <>
Subject Re: Cluster/Federated Artemis problems
Date Mon, 25 Jan 2016 16:35:36 GMT
  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.

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