delay failover transfer

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

delay failover transfer

Charels_Li
Hi guys. I am using failover + broker network for disaster transfer. So i config two brokers using static network and on client side i specifies failover like this.

failover:(tcp://localhost:61617,tcp://localhost:61618)?randomize=false)

My question is, when i kill the main broker, I may need the client take a few seconds to see if it could regain connection to the main broker before any connect attempt to the backup one.

Any idea is welcome.
Reply | Threaded
Open this post in threaded view
|

Re: delay failover transfer

gtully
there is currently no way to say retryCurrent X times before trying an
alternative url in the list and url must be unique so
there is no way to hack in duplicates.
maybe create a jira to track the enhancement to allow a retryCount on
the current url before moving on through the list.

On 24 April 2014 09:24, Charels_Li <[hidden email]> wrote:

> Hi guys. I am using failover + broker network for disaster transfer. So i
> config two brokers using static network and on client side i specifies
> failover like this.
>
> failover:(tcp://localhost:61617,tcp://localhost:61618)?randomize=false)
>
> My question is, when i kill the main broker, I may need the client take a
> few seconds to see if it could regain connection to the main broker before
> any connect attempt to the backup one.
>
> Any idea is welcome.
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/delay-failover-transfer-tp4680504.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.



--
http://redhat.com
http://blog.garytully.com
Reply | Threaded
Open this post in threaded view
|

Re: delay failover transfer

chiragpujara
have you looked at startupMaxReconnectAttempts and maxReconnectAttempts.


On Tue, Apr 29, 2014 at 7:23 AM, Gary Tully <[hidden email]> wrote:

> there is currently no way to say retryCurrent X times before trying an
> alternative url in the list and url must be unique so
> there is no way to hack in duplicates.
> maybe create a jira to track the enhancement to allow a retryCount on
> the current url before moving on through the list.
>
> On 24 April 2014 09:24, Charels_Li <[hidden email]> wrote:
> > Hi guys. I am using failover + broker network for disaster transfer. So i
> > config two brokers using static network and on client side i specifies
> > failover like this.
> >
> > failover:(tcp://localhost:61617,tcp://localhost:61618)?randomize=false)
> >
> > My question is, when i kill the main broker, I may need the client take a
> > few seconds to see if it could regain connection to the main broker
> before
> > any connect attempt to the backup one.
> >
> > Any idea is welcome.
> >
> >
> >
> > --
> > View this message in context:
> http://activemq.2283324.n4.nabble.com/delay-failover-transfer-tp4680504.html
> > Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>
>
> --
> http://redhat.com
> http://blog.garytully.com
>
Reply | Threaded
Open this post in threaded view
|

Re: delay failover transfer

Charels_Li
I tried that one, but it didnt make a difference. With my observation, this configuration controls how many times a client tries to reconnect to the main broker after it already transfers to the backup one. Did I miss anything? I just add startupMaxReconnectAttempts right after failover urls on client side.
Reply | Threaded
Open this post in threaded view
|

Re: delay failover transfer

artnaseef
Why would the client want to keep trying the master for a little while rather than immediately jump to the first available broker?

If the client really needs custom logic on connection failure, sounds like using the failover transport may not be the answer.
Reply | Threaded
Open this post in threaded view
|

Re: delay failover transfer

Charels_Li
The network of my firm was built a couple of years ago, whose bandwidth is limited. We are afraid there could be some lag/jam in data transmission. Say, a client losses contact with the broker due to an occasional network lag, but the connection could come to life after 2/3 seconds. In this case, we dont like the client switch forward/ backward for it could create some delay and message loss.

Shall i use failover transport? Or there's some sophisticated configs i could try?
Reply | Threaded
Open this post in threaded view
|

Re: delay failover transfer

Petter Nordlander
There is actually rather good documentation about such features on
http://activemq.apache.org/failover-transport-reference.html.

I would check out the ²priorityBackup² feature, that will try to keep the
connection to a primary broker, if possible. It might or might not suit
your needs.

failover:(tcp://local:61616,tcp://remote:61616)?randomize=false&priorityBac
kup=true

However, your connection should not drop on a simple sub second network
lag. Something else is dropping your connection.


I would also reconsider configuring the broker network in a way that you
don¹t lose messages. A switch might cost some slight delay (use the backup
feature to avoid that delay), but shouldn¹t affect the client more than
that.


BR Petter



Den 2014-05-05 04:40 skrev Charels_Li <[hidden email]>:

>The network of my firm was built a couple of years ago, whose bandwidth is
>limited. We are afraid there could be some lag/jam in data transmission.
>Say, a client losses contact with the broker due to an occasional network
>lag, but the connection could come to life after 2/3 seconds. In this
>case,
>we dont like the client switch forward/ backward for it could create some
>delay and message loss.
>
>Shall i use failover transport? Or there's some sophisticated configs i
>could try?
>
>
>
>--
>View this message in context:
>http://activemq.2283324.n4.nabble.com/delay-failover-transfer-tp4680504p46
>80841.html
>Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: delay failover transfer

Charels_Li
Thanks Petter.

I tried the configs and they work as supposed. What I am worrying is, when the main broker is down for some reason, and clients are transferring to the backup one. During the transfer, if I start the main again, the clients begin to come back to the main one. In such a case, lag could be huge.

BTW, I am using about 10,000 topics and 10,000 consumers, one topic one consumer. When i kill the main, the client takes about 20+ seconds to transfer to the backup one. I assume register 10,000 consumers on the backup broker could take that time. Is there anything i could do to improve the performance during the transfer?

Thanks

Charlie
Reply | Threaded
Open this post in threaded view
|

Re: delay failover transfer

artnaseef
In reply to this post by Charels_Li
Ah, very interesting use-case.  Aren't there networking-level solutions that will handle such a scenario at the ip-packet-routing level?  That would eliminate the need to solve it at the higher, ActiveMQ level.

Just an idea.