see: http://activemq.apache.org/configuring-transports.html "Server side options"
On 9 April 2013 20:05, Gary Tully <gary.tu...@gmail.com> wrote: > it may be worth looking at the transportconnector (broker side) > options, updateClusterClientsOnRemove=true and > updateClusterClients=true. > I that way the client should only be aware of the priority > availability when it returns to the cluster. > > If that does not work, raise an enhancement, the sending thread should > learn about the priority broker return in an async manner and get > notified. > > patches are always welcome :-) > > > On 9 April 2013 14:12, ByteFlinger <byteflin...@gmail.com> wrote: >> Hi >> >> I have setup a network of 2 brokers connected to each other and I am >> performing some tests towards them. >> >> I have setup prioritizedBackup so that if broker 1 goes down and later on >> comes up again, the producers will connect themselves back to that broker >> rather than keep sending messages to broker 2. >> >> I have noticed that as soon as I bring broker 1 down, it seems that activemq >> will try to reconnect itself to that broker after sending every single >> message and since it takes some time to timeout (and that the same thread >> seems to be used to reconnect thus blocking sending the next message), that >> means that even though broker 2 is up and running, sending messages to it >> takes considerably more time when broker 1 is down than it does otherwise. >> >> Is this normal behavior? If so, is there any way to tweak that so that it >> only tries to reconnect every X messages or maybe that it uses a separate >> thread to check whether that broker is up or not? Any other suggestions on >> how one can overcome this issue are welcome. >> >> Regards >> ByteFlinger >> >> >> >> -- >> View this message in context: >> http://activemq.2283324.n4.nabble.com/PrioritizedBackup-slows-down-producers-tp4665763.html >> Sent from the ActiveMQ - User mailing list archive at Nabble.com. > > > > -- > http://redhat.com > http://blog.garytully.com -- http://redhat.com http://blog.garytully.com
