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/
