[
https://issues.apache.org/activemq/browse/AMQNET-241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=58121#action_58121
]
Timothy Bish commented on AMQNET-241:
-------------------------------------
Well that definitely isn't what the maxReconnectAttempts is giving you, the
purpose of that flag is to limit the number of times the FailoverTransport is
going to try and connect to any of the configured brokers before giving up.
Once you hit that ceiling then no more connection attempts are made.
The failover transport in NMS doesn't appear to have it implemented but in the
Java version there is a timeout configuration opition that controls how long a
send blocks before it fails with an exception, this is most likely more along
the lines of what you want. You can open an enhancement request to have that
added into the next release of NMS.ActiveMQ.
> 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.
