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 Tue, 09 Mar 2010 22:47:45 GMT

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

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

Yes, that's still an issue, I'm planning on looking into that tomorrow.

> 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, NmsRepro_clean.zip
>
>
> 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