Return-Path: Delivered-To: apmail-activemq-dev-archive@www.apache.org Received: (qmail 49795 invoked from network); 9 Jun 2008 14:01:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Jun 2008 14:01:21 -0000 Received: (qmail 43890 invoked by uid 500); 9 Jun 2008 14:01:24 -0000 Delivered-To: apmail-activemq-dev-archive@activemq.apache.org Received: (qmail 43716 invoked by uid 500); 9 Jun 2008 14:01:23 -0000 Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@activemq.apache.org Delivered-To: mailing list dev@activemq.apache.org Received: (qmail 43694 invoked by uid 99); 9 Jun 2008 14:01:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Jun 2008 07:01:23 -0700 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Jun 2008 14:00:42 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 616B5234C136 for ; Mon, 9 Jun 2008 07:01:00 -0700 (PDT) Message-ID: <6375556.1213020060397.JavaMail.jira@brutus> Date: Mon, 9 Jun 2008 07:01:00 -0700 (PDT) From: "Andreas Kuhtz (JIRA)" To: dev@activemq.apache.org Subject: [jira] Reopened: (AMQ-1771) Failover transport should always signal resume of transport In-Reply-To: <1450256464.1212665340256.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ 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.