In this case static: will do what you want.
On 30 October 2014 16:52, Tim Bain wrote:
> What you're suggesting sounds like it would behave the same as if I use the
> static: transport with two nested URIs, except that I'd have more
> configuration boilerplate since I'd have an additional network
What you're suggesting sounds like it would behave the same as if I use the
static: transport with two nested URIs, except that I'd have more
configuration boilerplate since I'd have an additional networkConnector on
which I'd have to set all of my config options. Do I get something from
using the
you may be able to achieve what you want with two network connectors. one
to the primary and one to the backup. When both are alive and you use
decreaseNetworkConsumerPriority and priority dispatch, messages should take
the shortest path (priority decreases with number of hops).
On 24 October 2014
Gary,
I was able to get failover working between brokers in a network of brokers
using the maxReconnectAttempts=0 URI option. However, when I tried adding
priorityBackup=true, I ran into problems.
http://activemq.2283324.n4.nabble.com/priorityBackup-not-supported-with-masterslave-td4677626.html#a
Sounds good; thanks for the explanation.
On Mon, Sep 29, 2014 at 4:17 AM, Gary Tully wrote:
> everything is possible! but they evolved independently, hence the overlap
> in functionality
>
> On 26 September 2014 16:02, Tim Bain wrote:
>
> > Would it be possible for the failover transport to use
everything is possible! but they evolved independently, hence the overlap
in functionality
On 26 September 2014 16:02, Tim Bain wrote:
> Would it be possible for the failover transport to use the same
> DiscoveryListener mechanism that the static transport uses, but that's just
> not how it's be
Would it be possible for the failover transport to use the same
DiscoveryListener mechanism that the static transport uses, but that's just
not how it's been implemented? Or is there something fundamental about why
static is allowed to do its own reconnections (notifying the bridge via the
event h
the failover transport maintains a bunch of state -
connections/sessons/producers/consumers/transactions/messags/acks so that
it can replay those to maintain and recreate the jms client view.
However, a netwok bridge is not a standard jms client - specifically in the
duplex case but I think there p
Based on the comments that you and Torsten made in the links from my first
message, I had understood that for networkConnectors between brokers, you
should not allow the discovery transport to perform reconnects, because it
was important for the network bridge to be notified of the disconnection
an
maxReconnectAttempts=0 relates to the use of failover only, where you use
failover to choose between a list of broker urls (typically a pair for
master slave). masterSlave sets maxReconnectAttempts=0 on the underlying
failover url.
The static discovery, which is implemented by the SimpleDiscoveryAg
10 matches
Mail list logo
