Hi Tim,
Thank for the additional info. I actually use the failover transport regularly
for clients, so am aware of the priorityBackup option - thanks all the same.
To be honest, I'm not surprised about the failover transport being unavailable,
it's not listed anywhere in the network of brokers
For the second option, I think you'll also want to set the priorityBackup
option (see the Priority Backup section of
https://activemq.apache.org/failover-transport-reference.html) to get the
behavior of failing back to the fast link when it becomes available once
again.
I'm very surprised to hear
These are broker logs, or client logs? Whichever it is, what's in the other
process's logs at the same time?
You said that reconnecting isn't possible for hours after this happens. Do
you see the same messages in the logs for that whole time?
At the time this happens, what are the client(s) and t
Hello,
We need support. Many devices disconnect for no apparent reason and
cannot reconnect after several days. Could you help us solve this
problem? Here is an example in the logs :
2021-11-02 10:30:44,413 | WARNÂ | Transport Connection to:
tcp://62.83.10.35:1024 failed |
org.apache.active
Hi Gary,
Thank you for the reply, both solutions would be perfect for what I need.
With the first suggestion, I am unaware how to set the consumer base priority.
I'm not running an integrated broker, standalone where all my configurations
are withing the activemq.xml. I do apologise if I'm miss
there is one tweak with
org.apache.activemq.network.NetworkBridgeConfiguration#setConsumerPriorityBase
which could be used to bias the fast links, set that to -1 for the
fast links and the others will default to -5, so even with more
brokers the fast links will have "higher" priority.
the other op
