By the way, I've noticed Lars has run into the same issue and posted via Nabble but it hasn't turned up on the mailing list yet:
http://activemq.2283324.n4.nabble.com/Using-a-NetworkConnector-results-in-high-CPU-load-td4691627.html > On 20 Feb 2015, at 12:16 pm, Tim Robbins <tim.robb...@outlook.com> wrote: > > Hi, > > We’ve noticed a regression in ActiveMQ 5.10.1 vs. 5.10.0 with a configuration > similar to the following: > > Broker 1: > networkConnector with static:(failover:(tcp://broker2 > <tcp://broker2>)?randomize=false&maxReconnectAttempts=0) > > Broker 2: > networkConnector with static:(failover:(tcp://broker1 > <tcp://broker1>)?randomize=false&maxReconnectAttempts=0) > > When one of the brokers is restarted, the other broker uses ~400% CPU. The > cause is the FailoverTransport reconnectTask spinning, and nothing is > stopping the task. > > Reverting this fix made for AMQ-5315, while it does reintroduce the > NullPointerException, does handle failover properly without spinning: > https://git1-us-west.apache.org/repos/asf/activemq/repo?p=activemq.git;a=commitdiff;h=c391321d1b5b59542d847717654b0d4dba54cf2f > > <https://git1-us-west.apache.org/repos/asf/activemq/repo?p=activemq.git;a=commitdiff;h=c391321d1b5b59542d847717654b0d4dba54cf2f> > > The reason it works after reverting that change is the NullPointerException > is caught, -> serviceLocalException() -> > ServiceSupport.dispose(getControllingService()); with the fix made in > AMQ-5315, the dispose() call is never made. > > I think, rather than reverting the AMQ-5315 commit, it would be fine to just > call dispose() before fireBridgeFailed() in the case where we can’t retrieve > the broker info > > This does seem like a fairly serious problem; as far as I’m aware this is a > common use case; anyone using the masterslave transport or the failover > transport w/ the required maxReconnectAttempts=0 for bridges would be exposed > to it for example. > > Regards, > > Tim >
