activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Davies <rajdav...@gmail.com>
Subject Re: Duplex and network fault.
Date Wed, 21 Jul 2010 11:01:41 GMT
Hi Eric,

yes I think this is the case - I think we need to ensure that the old connection is destroyed
when the new one joins

cheers,

Rob


Rob Davies
follow me: http://twitter.com/rajdavies
I work here: http://fusesource.com
My Blog: http://rajdavies.blogspot.com/
I wrote this: http://www.manning.com/snyder/




On 21 Jul 2010, at 10:09, Eric-AWL wrote:

> 
> I was wrong.
> 
> here :
> 
> STOP : Network Fault : Network Off
> 
> Link 1 : ADMIN Link port 61601 : (DUPLEX back) Link from SIBBusModule
> TestDeCharge(Client) to SIBBusSupervisor port 61601, broken
> 2010-07-19 14:00:23,733 [isor-td0sib01s]] INFO  DemandForwardingBridge        
> - SIBBusSupervisor-td0sib01s bridge to SIBBusModule-TestDeCharge-td0sib01v
> stopped
> 
> So the bridge was only destroyed by the InactivityMonitor thread.
> 
> This trace was associated to another not Duplex bridge with the same
> brokers, and not the duplex one.
> 
> 
> But I have two questions :
> 
> I understand that when a network fault is detected on the "network
> connector" side of a duplex connection, the bridge is stopped on this side,
> but the other bridge side (transport side) is detected only by the
> InactivityMonitor. Is this true ?
> 
> In this case, if a new DemandForwardingBridge is created between the 2
> brokers, then the "transport side" sees temporarily (while InactivityMonitor
> doesn't destroy the first bridge) 2 brokers instead of one, and can send
> back some messages by using the faulty connection. Is this true ?
> 
> Thank you in advance
> 
> Eric-AWL
> 
> 
> 
> Eric-AWL wrote:
>> 
>> SIBBusModule-TestDeCharge-td0sib01v  Log
>> Link 1 : ADMIN Link port 61601 : Try to connect (DUPLEX initiator) from
>> SIBBusModule TestDeCharge (Client) to SIBBusSupervisor port 61601
>> 2010-07-19 09:57:18,896 [arge-td0sib01v]] INFO  DiscoveryNetworkConnector     
>> - Establishing network connection from
>> vm://SIBBusModule-TestDeCharge-td0sib01v to
>> tcp://td0sib01s.priv.atos.fr:61601?useLocalHost=false
>> 
>> Link 1 : ADMIN Link port 61601 : Connect (DUPLEX initiator)  from
>> SIBBusModule TestDeCharge (Client) to SIBBusSupervisor port 61601
>> 2010-07-19 09:57:19,068 [rge-td0sib01v#4] INFO  DemandForwardingBridge        
>> - Network connection between vm://SIBBusModule-TestDeCharge-td0sib01v#4
>> and
>> tcp://td0sib01s.priv.atos.fr/10.21.195.130:61601(SIBBusSupervisor-td0sib01s)
>> has been established.
>> 
>> 
>> STOP : Network Fault : Network Off
>> 
>> Link 1 : ADMIN Link port 61601 : (DUPLEX initiator) Link from SIBBusModule
>> TestDeCharge(Client) to SIBBusSupervisor port 61601, broken
>> 2010-07-19 14:00:23,258 [arge-td0sib01v]] INFO  DemandForwardingBridge        
>> - SIBBusModule-TestDeCharge-td0sib01v bridge to SIBBusSupervisor-td0sib01s
>> stopped
>> 
>> Reconnect Processus : Network On
>> 
>> Link 1 new : ADMIN Link port 61601 : Try to connect (DUPLEX initiator)
>> SIBBusModule TestDeCharge(Client) to SIBBusSupervisor port 61601
>> 2010-07-19 14:00:55,737 [arge-td0sib01v]] INFO  DiscoveryNetworkConnector     
>> - Establishing network connection from
>> vm://SIBBusModule-TestDeCharge-td0sib01v to
>> tcp://td0sib01s.priv.atos.fr:61601?useLocalHost=false
>> 
>> Link 1 new : ADMIN Link port 61601 : Connect (DUPLEX
>> initiator)SIBBusModule TestDeCharge(Client) to SIBBusSupervisor port 61601
>> 2010-07-19 14:00:55,857 [ge-td0sib01v#11] INFO  DemandForwardingBridge        
>> - Network connection between vm://SIBBusModule-TestDeCharge-td0sib01v#11
>> and
>> tcp://td0sib01s.priv.atos.fr/10.21.195.130:61601(SIBBusSupervisor-td0sib01s)
>> has been established.
>> 
>> 
>> Link 1 doesn’t seem to work. 
>> 
>> SIBBusSupervisor log
>> 
>> Link 1 : ADMIN Link port 61601 : Connect (DUPLEX back) from SIBBusModule
>> TestDeCharge (Client) port 36485 to SIBBusSupervisor port 61601
>> 2010-07-19 09:57:19,097 [0.29.12.1:36485] INFO  TransportConnection           
>> - Created Duplex Bridge back to SIBBusModule-TestDeCharge-td0sib01v
>> 2010-07-19 09:57:19,097 [or-td0sib01s#12] INFO  DemandForwardingBridge        
>> - Network connection between vm://SIBBusSupervisor-td0sib01s#12 and
>> tcp:///10.29.12.1:36485(SIBBusModule-TestDeCharge-td0sib01v) has been
>> established.
>> 
>> STOP : Network Fault : Network Off
>> 
>> Link 1 : ADMIN Link port 61601 : (DUPLEX back) Link from SIBBusModule
>> TestDeCharge(Client) to SIBBusSupervisor port 61601, broken
>> 2010-07-19 14:00:23,733 [isor-td0sib01s]] INFO  DemandForwardingBridge        
>> - SIBBusSupervisor-td0sib01s bridge to SIBBusModule-TestDeCharge-td0sib01v
>> stopped
>> 
>> 
>> Reconnect Processus : Network On
>> 
>> Link 1 new : ADMIN Link port 61601 : Connect (DUPLEX back) from
>> SIBBusModule TestDeCharge (Client) port 33840 to SIBBusSupervisor port
>> 61601
>> 2010-07-19 14:00:55,920 [0.29.12.1:33840] INFO  TransportConnection           
>> - Created Duplex Bridge back to SIBBusModule-TestDeCharge-td0sib01v
>> 2010-07-19 14:00:55,921 [or-td0sib01s#22] INFO  DemandForwardingBridge        
>> - Network connection between vm://SIBBusSupervisor-td0sib01s#22 and
>> tcp:///10.29.12.1:33840(SIBBusModule-TestDeCharge-td0sib01v) has been
>> established.
>> 
>> STOP Old DUPLEX back Connection
>> 
>> Link 1 old : ADMIN Link port 61601 : (DUPLEX back) Link SIBBusModule
>> TestDeCharge (Client) port 36485 to SIBBusSupervisor port 61601 is broken
>> 2010-07-19 14:00:58,939 [Worker@1ecc696e] WARN  DemandForwardingBridge        
>> - Network connection between vm://SIBBusSupervisor-td0sib01s#12 and
>> tcp:///10.29.12.1:36485 shutdown due to a remote error:
>> org.apache.activemq.transport.InactivityIOException: Channel was inactive
>> for too long: /10.29.12.1:36485
>> 2010-07-19 14:00:58,945 [0.29.12.1:36485] INFO  DemandForwardingBridge        
>> - SIBBusSupervisor-td0sib01s bridge to SIBBusModule-TestDeCharge-td0sib01v
>> stopped
>> 
>> 
>> It seems that bridge on Link 1 is finally broken ???
>> 
>> Eric-AWL
>> 
>> 
>> Eric-AWL wrote:
>>> 
>>> Hi
>>> 
>>> In the case where network is alternatively on/off in a duplex multicast
>>> configuration, I first discovered that the "network connector side"
>>> broker was sometimes blocked on "RemoteBrokerNameKnownLatch" latch.
>>> 
>>> I think that I resolved this problem by 
>>> - adding a countdown() call on this latch at the end of the stop() method
>>> - correctly managing an exception to alert the discovery connector that
>>> the bridge was disposed during the start call.
>>> 
>>> Now, I think that I have a problem on the other side with this
>>> configuration.
>>> T0                                   - A duplex connection is correctly
>>> established
>>> T0+X minutes                    - the network is down, the duplex bridge
>>> back is stopped, but the corresponding transport (back) connection seems
>>> not to be closed
>>> T0+X minutes + x ms          - the networl is up : a new transport
>>> connection want to be established and is established
>>> T0+X minutes + y seconds   - the transport inactivity thread closes the
>>> old transport connection
>>> 
>>> (y seconds >> x milliseconds)
>>> 
>>> All seems Ok, but no message are exchanged with this bridge.
>>> 
>>> Eric-AWL
>>> 
>> 
>> 
> 
> -- 
> View this message in context: http://old.nabble.com/Duplex-and-network-fault.-tp29205793p29223448.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> 


Mime
View raw message