activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kozakevych (JIRA)" <jira+amq...@apache.org>
Subject [jira] [Updated] (AMQNET-561) CLONE - NMS Failover causes CPU utilization to spike if ActiveMQ is stopped.
Date Tue, 21 Feb 2017 13:58:44 GMT

     [ https://issues.apache.org/jira/browse/AMQNET-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Oleg Kozakevych updated AMQNET-561:
-----------------------------------
    Description: 
Looks like the issue reappeared again.

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.



  was:
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.




> CLONE - NMS Failover causes CPU utilization to spike if ActiveMQ is stopped.
> ----------------------------------------------------------------------------
>
>                 Key: AMQNET-561
>                 URL: https://issues.apache.org/jira/browse/AMQNET-561
>             Project: ActiveMQ .Net
>          Issue Type: Bug
>          Components: ActiveMQ
>         Environment: .NET 3.5
>            Reporter: Oleg Kozakevych
>            Assignee: Timothy Bish
>
> Looks like the issue reappeared again.
> 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 was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message