activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (JIRA)" <jira+amq...@apache.org>
Subject [jira] Commented: (AMQNET-241) NMS Failover causes CPU utilization to spike if ActiveMQ is stopped.
Date Mon, 08 Mar 2010 20:47:45 GMT

    [ https://issues.apache.org/activemq/browse/AMQNET-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58095#action_58095
] 

Timothy Bish commented on AMQNET-241:
-------------------------------------

The connectionFailure value is only set when the macReconnectAttempts option is set and the
Failover Transport has actually faiiled to reconnect that many times so there is no need for
it to ever be reset.  

My sample application sees a small spike in CPU if the connection is broken but returns to
normal as the reconnect delay extends, once reconnected it also remains steady, I'm not seeing
any consistent CPU loading from my NMS client.

Perhaps you can provide a sample that show the problem?

> NMS Failover causes CPU utilization to spike if ActiveMQ is stopped.
> --------------------------------------------------------------------
>
>                 Key: AMQNET-241
>                 URL: https://issues.apache.org/activemq/browse/AMQNET-241
>             Project: ActiveMQ .Net
>          Issue Type: Bug
>          Components: ActiveMQ
>    Affects Versions: 1.2.0
>         Environment: .NET 3.5
>            Reporter: Ted Carroll
>            Assignee: Timothy Bish
>             Fix For: 1.2.1, 1.3.0
>
>         Attachments: NMS_Failover_CPU_Spike1.patch
>
>
> 1)  Configure a simple program that attempts to connect to ActiveMQ with the url "activemq:failover:(tcp://localhost:61616)"
> 2)  Make sure activemq is not running on the local host
> 3)  Try to connect.
> 4)  Notice that the CPU utilization in the sample program is high.
> 5)  Start ActiveMQ.
> 6)  Notice that the connection is successful but the CPU utilization remains high.
> Expected:
> I expect, potentially, an initial spike in CPU utilization but not sustained high CPU.
> Diagnosis:
> In FailoverTransport.DoConnect() there is the following if statement:
>                 if(ConnectedTransport != null || disposed || connectionFailure != null)

>                 { 
>                     return false; 
>                 } 
>                 else 
> it apears that connectionFailure is set and never reset.  Then the FailoverTask.Iterate()
calls into DoConnect only to return false immediately every time.
> I have attached a patch, but I would be uncomfortable calling it a long term solution
as I've not had the time to fully understand the code in question.  However, it seems to improve
the behavior.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message