[
https://issues.apache.org/activemq/browse/AMQ-1771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Kuhtz reopened AMQ-1771:
--------------------------------
There is another timing issue because the reconnect task is triggered via the
{{FailoverTransport.add(URI u[])}} method before the connection is configured
(see {{ActiveMConnectionFactory.createActiveMQConnection(...)}}) and therefore
the transport listener is not set.
The attached patch (amq-failover-reconnect.patch) checks if the transport is
started and does not call {{reconnect()}} because the {{start()}} will do it
later after the connection is configured.
> Failover transport should always signal resume of transport
> -----------------------------------------------------------
>
> Key: AMQ-1771
> URL: https://issues.apache.org/activemq/browse/AMQ-1771
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.1.0
> Environment: WinXP, JDK5
> Reporter: Andreas Kuhtz
> Assignee: Rob Davies
> Fix For: 5.2.0
>
> Attachments: amq-failover-reconnect.patch, amq-failover.patch
>
>
> The FailoverTransport does currently not signal the initial resume of the
> transport (due to race condition) nor the failure (if maxReconnectAttempts is
> 0) and therefore we don't know if the connection is successfully connected or
> not.
> The attached patch adds a sleep (copied from the failure processing part some
> lines below) that ensures that the ??transportListener?? is set and the
> ??transportListener.transportResumed()?? is called.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
