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.
