Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Message-ID: <16299060.383961295079547816.JavaMail.jira@thor>
Date: Sat, 15 Jan 2011 03:19:07 -0500 (EST)
From: "Raman Gupta (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Subject: [jira] Updated: (AMQ-3137) Outbound bridges should handle remote
 connectivity problems at startup
In-Reply-To: <8217212.383941295079405204.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Raman Gupta updated AMQ-3137:
-----------------------------

    Attachment: bridge_outbound_remote_reconnect.patch

Patch

> Outbound bridges should handle remote connectivity problems at startup
> ----------------------------------------------------------------------
>
>                 Key: AMQ-3137
>                 URL: https://issues.apache.org/jira/browse/AMQ-3137
>             Project: ActiveMQ
>          Issue Type: Improvement
>          Components: Connector
>    Affects Versions: 5.4.2
>            Reporter: Raman Gupta
>         Attachments: bridge_outbound_remote_reconnect.patch
>
>
> With a JMS-to-JMS bridge, one can configure JmsQueueConnector or JmsTopicConnector in an outbound bridge mode. In this mode, the "foreign" JMS provider is a remote service and therefore subject to disconnections, failures, etc.
> While the connectors do support reconnecting to a remote provider, the connectors will not start up correctly if the remote service is not available at start-up time.
> The attached patch (with test cases) solves this problem by separating the initialization of the local and remote parts of the bridge. A failure during initialization of the remote broker is not considered fatal, since the bridge attempts to reconnect to the foreign provider when a message is received from the local broker anyway. 
> This logic could also be implemented for inbound bridges but slightly more difficult in that it'll require a separate Thread to manage the connectivity state to the remote i.e. if the system fails to connect to the remote at startup time, a separate Thread can be created to periodically continue to try to connect. This would also apply for inbound bridges that lose their connection due to the remote losing connectivity or being recycled. This has not been done yet.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.