activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted C." <t...@verdiem.com>
Subject Re: NMS Failover transport pegging CPU
Date Fri, 05 Mar 2010 01:03:16 GMT

I'm happy to do so, will probably be tomorrow.  Just as a note, I think that
I'm getting this because in FailoverTransport there's the following if:

                if(ConnectedTransport != null || disposed ||
connectionFailure != null)
                {
                    return false;
                } 
                else



it appears (as in I've seen this in a couple of iterations and haven't
gotten back to it, yet) that connectionFailure is not null, so there's an
immediate return false and the the loop spins.

Speaking of which, I'm not sure I see a way for connectionFailure to ever
become null again.  It appears that it's only assigned in the else part of
the if above.  Am I missing something?

Thanks,

Ted C.



Timothy Bish wrote:
> 
> On Tue, 2010-03-02 at 17:27 -0800, Ted C. wrote:
>> It appears that NMS is pegging the CPU.  In my scenario, there's one
>> broker
>> running and the broker goes down.  When that hapens, my CPU utilization
>> goes
>> to 100% and never recovers.
>> 
>> When I break into the program, I see that FailoverTask.Iterate is getting
>> called frequently.  I ran it under dotTrace and got the following:
>> 
>> 32.70 % Thread #105762776 - 14308 ms - 0 calls
>>   32.70 % System.Threading._ThreadPoolWaitCallback.PerformWaitCallback...
>> -
>> 14308* ms - 0 calls
>>     32.70 % Run - 14308* ms - 0 calls -
>> Apache.NMS.ActiveMQ.Threads.PooledTaskRunner.Run(Object)
>>       32.70 % RunTask - 14308* ms - 0 calls -
>> Apache.NMS.ActiveMQ.Threads.PooledTaskRunner.RunTask()
>>         32.70 % Iterate - 14308* ms - 0 calls -
>> Apache.NMS.ActiveMQ.Transport.Failover.FailoverTransport.FailoverTask.Iterate()
>>           23.59 % WaitOne - 10323* ms - 0 calls -
>> System.Threading.WaitHandle.WaitOne()
>>           8.22 % ReleaseMutex - 3597 ms - 0 calls -
>> System.Threading.Mutex.ReleaseMutex()
>>           0.67 % get_ConnectedTransport - 291 ms - 0 calls -
>> Apache.NMS.ActiveMQ.Transport.Failover.FailoverTransport.get_ConnectedTransport()
>>           0.22 % DoConnect - 97 ms - 0 calls -
>> Apache.NMS.ActiveMQ.Transport.Failover.FailoverTransport.DoConnect()
>> 
>> Anybody seen similar issues?  This is ActiveMQ 5.3 and NMS 1.2.0.
>> 
>> Thanks,
>> 
>> Ted C.
>> 
> 
> This isn't an issue that's been reported yet.  Could you raise a new
> Jira issue regarding this?  I'd expect that the initial failure would
> cause a spike in CPU but would expect that the reconnect delay would
> cause that to settle down as it increases.
> 
> Regards
> 
> 
> -- 
> Tim Bish
> 
> Open Source Integration: http://fusesource.com
> ActiveMQ in Action: http://www.manning.com/snyder/
> 
> Follow me on Twitter: http://twitter.com/tabish121
> My Blog: http://timbish.blogspot.com/
> 
> 
> 

-- 
View this message in context: http://old.nabble.com/NMS-Failover-transport-pegging-CPU-tp27763465p27788784.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Mime
View raw message