Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Date: Mon, 25 Jan 2016 10:02:44 -0500 (EST)
From: Justin Bertram <jbertram@apache.com>
To: users@activemq.apache.org
Message-ID: <1730129229.14590983.1453734164505.JavaMail.zimbra@redhat.com>
In-Reply-To: 
 <CA+xsaB3n_YD9uAPAWvA4RCjVAc2MSXPhdRSNcxJ=JrL-dBK=wQ@mail.gmail.com>
References: 
 <CA+xsaB3n_YD9uAPAWvA4RCjVAc2MSXPhdRSNcxJ=JrL-dBK=wQ@mail.gmail.com>
Subject: Re: Cluster/Federated Artemis problems
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Thread-Topic: Cluster/Federated Artemis problems
Thread-Index: gASgl6wrCZBORtMT/M8C52jP4bvdVw==

I imagine this is just a configuration issue somewhere.  We ship lots of ex=
amples 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).  Che=
ck out the "clustered-static-discovery" example and also see the documentat=
ion [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 recen=
tly released.


Justin

[1] http://activemq.apache.org/artemis/docs/1.1.0/clusters.html (see the "D=
iscovery using static Connectors" section)

----- Original Message -----
From: "Lachezar Dobrev" <l.dobrev@gmail.com>
To: users@activemq.apache.org
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"
    =3D UDPBroadcastEndpointFactory
      * group-host 239.1.2.3
      * group-port 12345
      * local-host (host)
      * local-port (random-high-port)
    =3D ConnectorInfos
      * "cluster-connector"
  - DiscoveryGroupConfiguration named "cluster-discovery"
    =3D UDPBroadcastEndpointFactory
      * group-host 239.1.2.3
      * group-port 12345
      * local-host (host)
      * local-port (random-high-port)
  - ClusterConnectionConfiguration named "cluster"
    =3D address: "cluster-address"
    =3D connectorName: "cluster-connector"
    =3D 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
=E2=80=A6cluster.impl.BroadcastGroupImpl in the broadcastConnectors() metho=
d. 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.