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] http://activemq.apache.org/artemis/docs/1.1.0/clusters.html (see the "Discovery using static Connectors" section) ----- Original Message ----- From: "Lachezar Dobrev" <[email protected]> To: [email protected] 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 239.1.2.3 * group-port 12345 * local-host (host) * local-port (random-high-port) = ConnectorInfos * "cluster-connector" - DiscoveryGroupConfiguration named "cluster-discovery" = UDPBroadcastEndpointFactory * group-host 239.1.2.3 * 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.
