[
https://issues.apache.org/jira/browse/AMQNET-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13219351#comment-13219351
]
Jim Gomes commented on AMQNET-371:
----------------------------------
A correction to what I stated previously. I just found out that we actually
have ActiveMQ 5.4.2 deployed, not 5.5.0. I suspect that there is something
related to the usage of temp queues that is causing this problem. I have
noticed a pattern where the client receives an Advisory message that a temp
queue was created, and then it gets the connection exception. It's only
consistency is around that notification. It usually takes a while before it
occurs. Meaning, many temp queues will be created/destroyed before the problem
occurs.
> NMSConnectionException does not trigger failover recovery.
> ----------------------------------------------------------
>
> Key: AMQNET-371
> URL: https://issues.apache.org/jira/browse/AMQNET-371
> Project: ActiveMQ .Net
> Issue Type: Bug
> Components: ActiveMQ, Stomp
> Affects Versions: 1.5.3
> Reporter: Jim Gomes
> Assignee: Jim Gomes
> Labels: broker, error, exception, failover
> Fix For: 1.5.4, 1.6.0
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When a failover protocol is used, it is expected that any network
> interruptions will be automatically recovered. Currently, an internal broker
> error send an error message to a client and kick it off. The client then
> throws an NMSConnectionException. This exception is not automatically
> handled by the failover protocol, and the client application is then forced
> to completely destroy and rebuild all connections, sessions, consumers and
> producers, if that's even possible without restarting.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
