[ 
https://issues.apache.org/activemq/browse/AMQ-2774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=60825#action_60825
 ] 

Eric commented on AMQ-2774:
---------------------------

Hi

I think I now have programmed a clean correction for this specific latch 
problem. And I can give you the sources. With these sources, the network 
connector is not ever blocked even if a network fault comes during the start'() 
process.

But, before giving you these sources, I have relative questions, with duplex 
TCP connections :

Imagine a brief network fault

On the network connector side of the DUPLEX connection, the fault is detected, 
the TCP bridge is closed. Socket.close() is executed, but the socket is in a 
CLOSE_WAIT state.
The "transport connector side" of the DUPLEX connection is not aware that the 
first connection is down while its InactivityMonitor Thread doesn't signal it.

Then, on the network connector side, the bridge wants to be built again, and 
the network is now ON. The "transport connector side" creates a second active 
bridge for the same DUPLEX connection.
So, the "transport connector" side temporarily sees 2 distant broker for the 
same one, while the InactivityMonitor thread doesn't signal the death of the 
first TCP connection.

Is this true ?

Eric-AWL


> Network of brokers : Multicast discovery stopped to work
> --------------------------------------------------------
>
>                 Key: AMQ-2774
>                 URL: https://issues.apache.org/activemq/browse/AMQ-2774
>             Project: ActiveMQ
>          Issue Type: Bug
>    Affects Versions: 5.2.0
>         Environment: Linux
>            Reporter: Eric
>             Fix For: 5.4.1
>
>         Attachments: JMAC-BEA-lastlog.log-20100315
>
>
> Hi everybody
> I experiment a big problem with the multicast discovery algorithm, in a 
> network of brokers topology.
> In some conditions, a broker can't reestablish a distant connection even if 
> the distant broker is restarted.
> I have the log traces that would help to identify the origin of the problem.
> When there is no discovery/connection error, I can see these 2 lines in the 
> activemq log file
> #08 Jun 2010 14:31:30,639  INFO  [Multicast Discovery Agent Notifier] 
> org.apache.activemq.network.DiscoveryNetworkConnector
> Establishing network connection between from vm://ACCLU-tpnocp04v to 
> tcp://tpnocp09v-bus:13100?useLocalHost=false
> #08 Jun 2010 14:31:30,692  INFO  [StartLocalBridge: 
> localBroker=vm://ACCLU-tpnocp04v#26] 
> org.apache.activemq.network.DemandForwardingBridge
> Network connection between vm://ACCLU-tpnocp04v#26 and 
> tcp://tpnocp09v-bus/10.18.126.28:13100(MOM-tpnocp09v) has been established.
> When the connection is broken, I can see this line in the log.
> #11 Jun 2010 12:37:32,585  INFO  [Multicast Discovery Agent Notifier] 
> org.apache.activemq.network.DemandForwardingBridge
> ACCLU-tpnocp04v bridge to MOM-tpnocp09v stopped
> Then the current ACCLU-tpnocp04v broker tries to reestablish the connection :
> #11 Jun 2010 12:37:34,475  INFO  [Multicast Discovery Agent Notifier] 
> org.apache.activemq.network.DiscoveryNetworkConnector
> Establishing network connection between from vm://ACCLU-tpnocp04v to 
> tcp://tpnocp09v-bus:13100?useLocalHost=false
> But, here, the second line of the log ("has been established") doesn't appear 
> in the log file !! I don't know exactly if the connection is up or not.
> Then the connection is broken again (look at "Unknown" instead of 
> "MOM-tpnocp09v".
> #11 Jun 2010 13:33:58,655  WARN  [ActiveMQ Transport: 
> tcp://tpnocp09v-bus/10.18.126.28:13100] 
> org.apache.activemq.network.DemandForwardingBridge
> Network connection between vm://ACCLU-tpnocp04v#58 and 
> tcp://tpnocp09v-bus/10.18.126.28:13100 shutdown due to a remote error: 
> java.net.SocketException: Connection reset
> #11 Jun 2010 13:33:58,657  INFO  [NetworkBridge] 
> org.apache.activemq.network.DemandForwardingBridge^M
> ACCLU-tpnocp04v bridge to Unknown stopped
> And, now, even if I restart the distant broker ( MOM-tpnocp09v ), no line 
> (Establishing/Has been established) appears, and no network connection is 
> reestablished between ACCLU-tpnocp04v and MOM-tpnocp09v. it seems that this 
> ACCLU-tpnocp04v broker can no longer establish a connection with the 
> MOM-tpnocp09v broker !!!
> The production teams tell me that this problem seems not to be resolved in 
> fuse-5.3.0.6 version.
> Eric-AWL

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

Reply via email to