Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: neutral (nike.apache.org: 216.139.236.26 is neither permitted
 nor denied by domain of rasmus.back@gmail.com)
Date: Wed, 23 Mar 2011 01:45:51 -0700 (PDT)
From: rasmusback <rasmus.back@gmail.com>
To: users@activemq.apache.org
Message-ID: <AANLkTi=E-owu9=qreF9JLUe9yfQE6bUu63TRs2myV9qz@mail.gmail.com>
In-Reply-To: <AANLkTimRecgtfheXGYfqSvM28Hy3Et+t+YMeQRFFNK=2@mail.gmail.com>
References: <1300804279026-3396540.post@n4.nabble.com>
 <AANLkTimRecgtfheXGYfqSvM28Hy3Et+t+YMeQRFFNK=2@mail.gmail.com>
Subject: Re: Clients can get stuck in a reconnect loop with master-slave
 brokers
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_2643_9840131.1300869951786"

------=_Part_2643_9840131.1300869951786
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Gary,

On Tue, Mar 22, 2011 at 5:16 PM, Gary Tully [via ActiveMQ]
<ml-node+3396678-858026179-223157@n4.nabble.com> wrote:
> The test needs some mods to ensure that the slave broker listen port
> is only started when the broker becomes the baster.
>
> In code, the addition of the transportConnector needs to be:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 // lazy create transport connector on start c=
ompletion
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 TransportConnector connector =3D new Transpor=
tConnector();
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 connector.setUri(new URI("tcp://localhost:" +=
 listenPort));
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 broker.addConnector(connector);

Ok, so I need to add a check to the broker initialization before
adding the connector. There's a waitUntilStarted method in
BrokerService, is this the one to use? A quick test with

broker.start();
broker.waitUntilStarted();
broker.addConnector("tcp://localhost:"+port);

did not make the test pass. I'm looking at the embedded broker FAQ
page and the BrokerService API documentation, but it doesn't provide
much help for this scenario.

> In cases where failover needs to abort you can configure the
> maxReconnectAttempts to be > 0 and it will fail with an exception
> after X attempts.

Yep, I tried to keep the amount of options to a minimum in the test
case. In the case I'm describing there is a broker up and running, the
failover transport just doesn't get around to connecting to it.

> On 22 March 2011 14:31, rasmusback <[hidden email]> wrote:
>> Hi,
>>
>> I'm using the shared file system, master slave setup with two brokers on
>> separate servers. My clients are configured to use the failover transpor=
t
>> with a URL like this:
>> failover://(tcp://broker1:61616,tcp://broker2:61616)?randomize=3Dfalse. =
I've
>> noticed that the order of the brokers in the failover URL seems to be
>> significant. If I start broker2 before broker1, so that broker2 becomes
>> the
>> master and broker1 the slave, clients will get stuck in a reconnect loop
>> where they keep trying to connect to broker1.
>>
>> Attached is a junit test case which exhibits the same behavior as my
>> setup.
>> If the startup order of the brokers is different from their order in the
>> failover URL, the test will timeout. When the order is the same, the tes=
t
>> will pass.
>>
>> The slave broker opens a socket, so a tcp connection is possible to it
>> even
>> though the broker functionality isn't enabled. This might be what is
>> confusing the failover transport.
>>
>> I'm not quite sure if my broker configuration is incorrect or if this is=
 a
>> bug (or feature) in a master slave setup, so any help is much appreciate=
d.
>> I'm using ActiveMQ 5.4.2 and spring-jms 2.5.5.
>>
>> =C2=A0 Rasmus
>>
>> http://activemq.2283324.n4.nabble.com/file/n3396540/FailoverTest.java
>> FailoverTest.java
>>
>> --
>> View this message in context:
>> http://activemq.2283324.n4.nabble.com/Clients-can-get-stuck-in-a-reconne=
ct-loop-with-master-slave-brokers-tp3396540p3396540.html
>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>
>
>
> --
> http://blog.garytully.com
> http://fusesource.com
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://activemq.2283324.n4.nabble.com/Clients-can-get-stuck-in-a-reconnec=
t-loop-with-master-slave-brokers-tp3396540p3396678.html
> To unsubscribe from Clients can get stuck in a reconnect loop with
> master-slave brokers, click here.


--
View this message in context: http://activemq.2283324.n4.nabble.com/Clients=
-can-get-stuck-in-a-reconnect-loop-with-master-slave-brokers-tp3396540p3398=
869.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
------=_Part_2643_9840131.1300869951786--