Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CA+xsaB2zoi9+-=pKEe3wk6Pd0oAWhpJWEPNbyxbX8G5MCGuUjA@mail.gmail.com>
References: 
 <CA+xsaB3n_YD9uAPAWvA4RCjVAc2MSXPhdRSNcxJ=JrL-dBK=wQ@mail.gmail.com>
	<1730129229.14590983.1453734164505.JavaMail.zimbra@redhat.com>
	<CA+xsaB1vtP3j_GnA3S_H-QaQ11mmRb82XbuMLEBT+j_9EbSEag@mail.gmail.com>
	<1171707438.14656809.1453741184908.JavaMail.zimbra@redhat.com>
	<CA+xsaB2zoi9+-=pKEe3wk6Pd0oAWhpJWEPNbyxbX8G5MCGuUjA@mail.gmail.com>
Date: Tue, 26 Jan 2016 10:17:29 -0500
Message-ID: 
 <CAKF+bspVyY0fseynPP4UmSfVPf_36VBLz7YiOJtFeiz=CETuqQ@mail.gmail.com>
Subject: Re: Cluster/Federated Artemis problems
From: Clebert Suconic <clebert.suconic@gmail.com>
To: users@activemq.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

just to let you know.. to build with checkstyle activated, you have to
build with the dev profile:

mvn -Pdev install (etc).


On Tue, Jan 26, 2016 at 6:14 AM, Lachezar Dobrev <l.dobrev@gmail.com> wrote=
:
>   Well, not that you have explained this it is really "Obvious".
>   I'm using Artemis as JMS client+server, and internals are a bit obscure
> for me. I'll have to wrap my head around the fact, that there is more tha=
n
> JMS to that.
>
>   Package size issue:
>   https://issues.apache.org/jira/browse/ARTEMIS-362
>
>   Git Pull-Request with fix and test case:
>   https://github.com/apache/activemq-artemis/pull/348
>
>   Jenkins does not like me however, The build passed, but the pull reques=
t
> is marked erroneous:
>   https://builds.apache.org/job/ActiveMQ-Artemis-PR-Build/965/
>
>   Please advise.
>
>   Lachezar
>
> 2016-01-25 18:59 GMT+02:00 Justin Bertram <jbertram@apache.com>:
>
>> The documentation is pretty clear (IMO) about the purpose of the "addres=
s"
>> 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 documentat=
ion
>> 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 a=
nd
>> outline a way I can observe that myself that would go a long way in maki=
ng
>> sure the issue is resolved.  Thanks!
>>
>>
>> Justin
>>
>> [1] http://activemq.apache.org/artemis/docs/1.1.0/clusters.html (see the
>> "Configuring Cluster Connections" section)
>> [2] http://activemq.apache.org/artemis/docs/1.1.0/jms-core-mapping.html
>> [3] https://issues.apache.org/jira/browse/ARTEMIS
>>
>> ----- Original Message -----
>> From: "Lachezar Dobrev" <l.dobrev@gmail.com>
>> To: users@activemq.apache.org
>> 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 tha=
t 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 <jbertram@apache.com>:
>>
>> > I imagine this is just a configuration issue somewhere.  We ship lots =
of
>> > examples which use clustering (although not embedded), and the test-su=
ite
>> > 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 t=
he
>> > "Discovery 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 Arte=
mis
>> > embedded server.
>> >   The application is a .WAR with Springframework 4 and Embedded Artemi=
s
>> > 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 Top=
ic
>> > 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() =
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 hundr=
ed
>> > 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, b=
ut
>> > 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.
>> >
>>


--=20
Clebert Suconic