You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by natron <na...@adelphia.net> on 2006/04/26 22:18:30 UTC
Network Connector Configuration
I am having a problem where I have 2 network connectors from a single broker.
Basically, I just want all data flowing through the "main" broker to be
mirrored onto the 2 brokers specified in the network connectors. The
problem is that if one or both of the brokers specified in the network
connectors goes down, eventually the main broker will block everything until
both of the other brokers are back up.
Is there a setting that will cause this NOT to happen? I don't want my main
broker blocking all traffic and waiting on the other network connectors. I
just want everything to be passed onto them if they *happen* to be up and
running.
Here is my configuration, as you can see, I tried setting "dynamicOnly" to
true but that doesn't seem to have fixed it:
<networkConnectors>
<networkConnector name="broker_A" uri="static://tcp://192.168.1.101:61616"
failover="true" dynamicOnly="true"/>
<networkConnector name="broker_B" uri="static://tcp://192.168.1.102:61616"
failover="true" dynamicOnly="true"/>
</networkConnectors>
Thanks,
Natron
--
View this message in context: http://www.nabble.com/Network-Connector-Configuration-t1513987.html#a4108935
Sent from the ActiveMQ - User forum at Nabble.com.
Re: Network Connector Configuration
Posted by Rob Davies <ra...@gmail.com>.
An option would be to listen for transport failures in the
remoteBroker transport and stop (and unwind) the local broker
transport on failure - and only re-connect when the remote broker
transport is re-established. transportInterupted and transportResumed
was added to the TransportListener to do this type of stuff.
On 26 Apr 2006, at 23:29, Hiram Chirino wrote:
> That's one of the problems with using static discovery and not
> multicast discovery for the brokers.
>
> When you use static discovery with the failover option, the broker
> sees a transport to the remote side that never fails even when the
> remote broker has died. Messages sent over the failover transport
> will block until the remote broker is back online. This blocked
> network bridge is the same as having a slow consumer ( for more info
> see: http://www.activemq.org/Slow+Consumer+Handling ).
>
> In your case it would actually be good if the network bridge saw the
> transport fail. It would then kill the bridge and and you would not
> have the slow consumer situation. This can easily be done by
> disabling the failover feature. The problem is since your not using
> multicast discovery, there is event generated to let us know when the
> remote broker is back online.
>
> Perhaps we should enhance the static: discovery agent to do a periodic
> checks to see if a failed broker is back online. Once it's back
> online, then it would generate an event letting the network connector
> know that it's online again. Anybody fancy taking a stab at
> implementing this?
>
>
> On 4/26/06, natron <na...@adelphia.net> wrote:
>>
>> I am having a problem where I have 2 network connectors from a
>> single broker.
>> Basically, I just want all data flowing through the "main" broker
>> to be
>> mirrored onto the 2 brokers specified in the network connectors. The
>> problem is that if one or both of the brokers specified in the
>> network
>> connectors goes down, eventually the main broker will block
>> everything until
>> both of the other brokers are back up.
>>
>> Is there a setting that will cause this NOT to happen? I don't
>> want my main
>> broker blocking all traffic and waiting on the other network
>> connectors. I
>> just want everything to be passed onto them if they *happen* to be
>> up and
>> running.
>>
>> Here is my configuration, as you can see, I tried setting
>> "dynamicOnly" to
>> true but that doesn't seem to have fixed it:
>>
>> <networkConnectors>
>> <networkConnector name="broker_A" uri="static://tcp://
>> 192.168.1.101:61616"
>> failover="true" dynamicOnly="true"/>
>> <networkConnector name="broker_B" uri="static://tcp://
>> 192.168.1.102:61616"
>> failover="true" dynamicOnly="true"/>
>> </networkConnectors>
>>
>> Thanks,
>> Natron
>> --
>> View this message in context: http://www.nabble.com/Network-
>> Connector-Configuration-t1513987.html#a4108935
>> Sent from the ActiveMQ - User forum at Nabble.com.
>>
>>
>
>
> --
> Regards,
> Hiram
Re: Network Connector Configuration
Posted by yaussy <ya...@cboe.com>.
Yes, this solution works pretty well for us. Here is the whole
destinationPolicy section from my XML. I've set the eviction strategy for
all topics. Also, the pendingMessageLimitStrategy defines how big the queue
can get. There is the prefetch queue, then a pending queue. The
pendingMessageLimitStrategy I chose calculates the pending queue size based
upon the prefetch queue.
<destinationPolicy>
<policyMap><policyEntries>
<!-- Wildcard topic -->
<policyEntry topic=">">
<messageEvictionStrategy>
<oldestMessageEvictionStrategy />
</messageEvictionStrategy>
<pendingMessageLimitStrategy>
<prefetchRatePendingMessageLimitStrategy multiplier="0.5" />
</pendingMessageLimitStrategy>
</policyEntry>
</policyEntries></policyMap>
</destinationPolicy>
--
View this message in context: http://www.nabble.com/Network-Connector-Configuration-t1513987.html#a4140061
Sent from the ActiveMQ - User forum at Nabble.com.
Re: Network Connector Configuration
Posted by natron <na...@adelphia.net>.
Thanks, Yaussy - that may actually work for my configuration. Can you give
me a bit more detail as to where exactly I need to put the xml that you
mentioned?
Modifiying the default configuration that comes with AMQ, I think it should
look something like:
<destinationPolicy>
<messageEvictionStrategy>
<oldestMessageEvictionStrategy />
</messageEvictionStrategy>
<policyMap>
<policyEntries>
<policyEntry topic="FOO.>">
<dispatchPolicy>
<strictOrderDispatchPolicy/>
</dispatchPolicy>
<subscriptionRecoveryPolicy>
<lastImageSubscriptionRecoveryPolicy/>
</subscriptionRecoveryPolicy>
</policyEntry>
</policyEntries>
</policyMap>
</destinationPolicy>
Is that correct? I have never made any changes to the default.
Thanks for your help.
--
View this message in context: http://www.nabble.com/Network-Connector-Configuration-t1513987.html#a4130123
Sent from the ActiveMQ - User forum at Nabble.com.
Re: Network Connector Configuration
Posted by yaussy <ya...@cboe.com>.
I've been asking for this for a while now. I'd love to see the changes
described by either Rob or Hiram. It's exactly what I've asked for
previously.
To work around this, I have specified:
<messageEvictionStrategy>
<oldestMessageEvictionStrategy />
</messageEvictionStrategy>
in the destinationPolicy section.
This way, when the broker goes away, the main broker does not block.
Limited queuing takes place, then discarding once the queue is filled up.
--
View this message in context: http://www.nabble.com/Network-Connector-Configuration-t1513987.html#a4124796
Sent from the ActiveMQ - User forum at Nabble.com.
Re: Network Connector Configuration
Posted by natron <na...@adelphia.net>.
Thanks for the reply. Any ideas for a work-around? Unfortunately using
multicast discovery won't work on my production system.
thanks,
Natron
--
View this message in context: http://www.nabble.com/Network-Connector-Configuration-t1513987.html#a4111376
Sent from the ActiveMQ - User forum at Nabble.com.
Re: Network Connector Configuration
Posted by Hiram Chirino <hi...@hiramchirino.com>.
That's one of the problems with using static discovery and not
multicast discovery for the brokers.
When you use static discovery with the failover option, the broker
sees a transport to the remote side that never fails even when the
remote broker has died. Messages sent over the failover transport
will block until the remote broker is back online. This blocked
network bridge is the same as having a slow consumer ( for more info
see: http://www.activemq.org/Slow+Consumer+Handling ).
In your case it would actually be good if the network bridge saw the
transport fail. It would then kill the bridge and and you would not
have the slow consumer situation. This can easily be done by
disabling the failover feature. The problem is since your not using
multicast discovery, there is event generated to let us know when the
remote broker is back online.
Perhaps we should enhance the static: discovery agent to do a periodic
checks to see if a failed broker is back online. Once it's back
online, then it would generate an event letting the network connector
know that it's online again. Anybody fancy taking a stab at
implementing this?
On 4/26/06, natron <na...@adelphia.net> wrote:
>
> I am having a problem where I have 2 network connectors from a single broker.
> Basically, I just want all data flowing through the "main" broker to be
> mirrored onto the 2 brokers specified in the network connectors. The
> problem is that if one or both of the brokers specified in the network
> connectors goes down, eventually the main broker will block everything until
> both of the other brokers are back up.
>
> Is there a setting that will cause this NOT to happen? I don't want my main
> broker blocking all traffic and waiting on the other network connectors. I
> just want everything to be passed onto them if they *happen* to be up and
> running.
>
> Here is my configuration, as you can see, I tried setting "dynamicOnly" to
> true but that doesn't seem to have fixed it:
>
> <networkConnectors>
> <networkConnector name="broker_A" uri="static://tcp://192.168.1.101:61616"
> failover="true" dynamicOnly="true"/>
> <networkConnector name="broker_B" uri="static://tcp://192.168.1.102:61616"
> failover="true" dynamicOnly="true"/>
> </networkConnectors>
>
> Thanks,
> Natron
> --
> View this message in context: http://www.nabble.com/Network-Connector-Configuration-t1513987.html#a4108935
> Sent from the ActiveMQ - User forum at Nabble.com.
>
>
--
Regards,
Hiram