Mailing-List: contact activemq-dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-dev@geronimo.apache.org
Message-ID: <23795770.1159908489223.JavaMail.root@brutus>
Date: Tue, 3 Oct 2006 13:48:09 -0700 (PDT)
From: "Sridhar Komandur (JIRA)" <jira@apache.org>
To: activemq-dev@geronimo.apache.org
Subject: [jira] Reopened: (AMQ-917) Discovery Network Connector needs to
 clean up internal ...
In-Reply-To: <8641978.1158014243100.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

     [ https://issues.apache.org/activemq/browse/AMQ-917?page=all ]

Sridhar Komandur reopened AMQ-917:
----------------------------------

             
I tested after apply the patch to the turnk (as of yesterday). It still breaks in a couple of  places even without the patch (an example below). I will attach the new patchfile.

> Discovery Network Connector needs to clean up internal ...
> ----------------------------------------------------------
>
>                 Key: AMQ-917
>                 URL: https://issues.apache.org/activemq/browse/AMQ-917
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Connector
>            Reporter: Sridhar Komandur
>         Assigned To: james strachan
>         Attachments: patchfile.txt
>
>
> Consider the following scenario: All the brokers are using a directory service based discovery agent (for example, DNS). Broker A comes up and tries to connect to broker B, which is not functional yet. The Discovery Network Connector at A adds service B to its tracking state "bridges" (list of connected services) before activating the connection. However, if there is a failure, the data structure is not cleaned up. When the DNS Discovery Agent module rescans (DNS)  and passes on uri for B into DNC, it simply ignores it (as its tracking state hasn't been cleaned up upon prior failure).
> The attached patch should take care of this issue (in the observed code path) - test log below:
> 2006-09-11 15:36:11,810 [main           ] INFO  network.DemandForwardingBridge1 - Starting a network connection between vm://localhost#0 and tcp://null:0 has been established.
> 2006-09-11 15:36:48,158 [main           ] DEBUG network.DemandForwardingBridge1 -  stopping localhost bridge to null is disposed already ? false
> 2006-09-11 15:36:48,158 [main           ] INFO  ransport.vm.VMTransportFactory1 - Shutting down VM connectors for broker: localhost
> 2006-09-11 15:36:48,159 [main           ] INFO  ransport.vm.VMTransportFactory1 - Shutting down VM connectors for broker: localhost
> 2006-09-11 15:36:48,162 [main           ] INFO  vemq.broker.TransportConnector1 - Connector vm://localhost Stopped
> 2006-09-11 15:36:48,162 [main           ] DEBUG network.DemandForwardingBridge1 - localhost bridge to null stopped
> 2006-09-11 15:37:11,246 [main           ] WARN  ivemq.network.NetworkConnector1 - Could not start network bridge between: vm://localhost?network=true and: tcp://komandur-2.desktop.amazon.com:61617 due to: java.net.ConnectException: Connection refused
> java.net.ConnectException: Connection refused

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira