Ok, I will try to add some code lines to avoid this case.... Not easy at first view.
Eric-AWL rajdavies wrote: > > 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 [wor...@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. >> > > > -- View this message in context: http://old.nabble.com/Duplex-and-network-fault.-tp29205793p29224397.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
