Duplex and network fault.

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Duplex and network fault.

Eric-AWL
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
Reply | Threaded
Open this post in threaded view
|

Re: Duplex and network fault.

Eric-AWL
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
Reply | Threaded
Open this post in threaded view
|

Re: Duplex and network fault.

Eric-AWL
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
Reply | Threaded
Open this post in threaded view
|

Re: Duplex and network fault.

rajdavies
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.
>

Reply | Threaded
Open this post in threaded view
|

Re: Duplex and network fault.

Eric-AWL
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 [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.
>
Reply | Threaded
Open this post in threaded view
|

Re: Duplex and network fault.

Eric-AWL

in TransportConnection class.

This TransportConnection is associated to a TransportConnector

public Response processBrokerInfo(BrokerInfo info) {
....
} else if (info.isNetworkConnection() && info.isDuplexConnection()) {
          try {
                Properties properties = MarshallingSupport.stringToProperties(info.getNetworkProperties());
                Map<String, String> props = createMap(properties);
   

            duplexBridge = NetworkBridgeFactory.createBridge(config, localTransport, remoteBridgeTransport);
                duplexBridge.setBrokerService(broker.getBrokerService());
                // now turn duplex off this side
                info.setDuplexConnection(false);
                duplexBridge.setCreatedByDuplex(true);
                duplexBridge.duplexStart(this, brokerInfo, info);
                LOG.info("Created Duplex Bridge back to " + info.getBrokerName());
...

I could use the current list of TransportConnection managed by the "parent" TransportConnector (which can be retreived in the TransportConnection class), to verify that a connection with the same brokerInfo.getBrokerId() is not already launched and throw an exception (and try to send it back) if the connection is always active ? Is it Ok ?

On the Transport Side, the new bridge won't be created while the InactivityMonitor doesn't destroy the old bridge.


Eric-AWL

Eric-AWL wrote
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 [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.
>
Reply | Threaded
Open this post in threaded view
|

Re: Duplex and network fault.

rajdavies
wouldn't you want to do it the other way round - destroy the current connection and use the new one ?

On 21 Jul 2010, at 17:27, Eric-AWL wrote:

>
>
> in TransportConnection class.
>
> This TransportConnection is associated to a TransportConnector
>
> public Response processBrokerInfo(BrokerInfo info) {
> ....
> } else if (info.isNetworkConnection() && info.isDuplexConnection()) {
>          try {
>                Properties properties =
> MarshallingSupport.stringToProperties(info.getNetworkProperties());
>                Map<String, String> props = createMap(properties);
>
>
>            duplexBridge = NetworkBridgeFactory.createBridge(config,
> localTransport, remoteBridgeTransport);
>                duplexBridge.setBrokerService(broker.getBrokerService());
>                // now turn duplex off this side
>                info.setDuplexConnection(false);
>                duplexBridge.setCreatedByDuplex(true);
>                duplexBridge.duplexStart(this, brokerInfo, info);
>                LOG.info("Created Duplex Bridge back to " +
> info.getBrokerName());
> ...
>
> I could use the current list of TransportConnection managed by the "parent"
> TransportConnector (which can be retreived in the TransportConnection
> class), to verify that a connection with the same brokerInfo.getBrokerId()
> is not already launched and throw an exception (and try to send it back) if
> the connection is always active ? Is it Ok ?
>
> On the Transport Side, the new bridge won't be created while the
> InactivityMonitor doesn't destroy the old bridge.
>
>
> Eric-AWL
>
>
> Eric-AWL wrote:
>>
>> 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 [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.
>>>>
>>>
>>>
>>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Duplex-and-network-fault.-tp29205793p29228003.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>

Reply | Threaded
Open this post in threaded view
|

Re: Duplex and network fault.

Eric-AWL
yes, it seems to be better and, finally easier to manage. I will try.

Do you confirm me that, in a normal situation, the transport connection should always be deleted from the current list before a new similar one wants to be created (thread synchronization) ?
I don't know how specific functions (failover connections for example) are managed.

Thank you
Eric-AWL

rajdavies wrote
wouldn't you want to do it the other way round - destroy the current connection and use the new one ?

On 21 Jul 2010, at 17:27, Eric-AWL wrote:

>
>
> in TransportConnection class.
>
> This TransportConnection is associated to a TransportConnector
>
> public Response processBrokerInfo(BrokerInfo info) {
> ....
> } else if (info.isNetworkConnection() && info.isDuplexConnection()) {
>          try {
>                Properties properties =
> MarshallingSupport.stringToProperties(info.getNetworkProperties());
>                Map<String, String> props = createMap(properties);
>
>
>            duplexBridge = NetworkBridgeFactory.createBridge(config,
> localTransport, remoteBridgeTransport);
>                duplexBridge.setBrokerService(broker.getBrokerService());
>                // now turn duplex off this side
>                info.setDuplexConnection(false);
>                duplexBridge.setCreatedByDuplex(true);
>                duplexBridge.duplexStart(this, brokerInfo, info);
>                LOG.info("Created Duplex Bridge back to " +
> info.getBrokerName());
> ...
>
> I could use the current list of TransportConnection managed by the "parent"
> TransportConnector (which can be retreived in the TransportConnection
> class), to verify that a connection with the same brokerInfo.getBrokerId()
> is not already launched and throw an exception (and try to send it back) if
> the connection is always active ? Is it Ok ?
>
> On the Transport Side, the new bridge won't be created while the
> InactivityMonitor doesn't destroy the old bridge.
>
>
> Eric-AWL
>
>
> Eric-AWL wrote:
>>
>> 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 [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.
>>>>
>>>
>>>
>>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Duplex-and-network-fault.-tp29205793p29228003.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Reply | Threaded
Open this post in threaded view
|

Re: Duplex and network fault.

Eric-AWL
I added a fix in the Jira AMQ-2774 thread.

Eric-AWL

Eric-AWL wrote
yes, it seems to be better and, finally easier to manage. I will try.

Do you confirm me that, in a normal situation, the transport connection should always be deleted from the current list before a new similar one wants to be created (thread synchronization) ?
I don't know how specific functions (failover connections for example) are managed.

Thank you
Eric-AWL

rajdavies wrote
wouldn't you want to do it the other way round - destroy the current connection and use the new one ?

On 21 Jul 2010, at 17:27, Eric-AWL wrote:

>
>
> in TransportConnection class.
>
> This TransportConnection is associated to a TransportConnector
>
> public Response processBrokerInfo(BrokerInfo info) {
> ....
> } else if (info.isNetworkConnection() && info.isDuplexConnection()) {
>          try {
>                Properties properties =
> MarshallingSupport.stringToProperties(info.getNetworkProperties());
>                Map<String, String> props = createMap(properties);
>
>
>            duplexBridge = NetworkBridgeFactory.createBridge(config,
> localTransport, remoteBridgeTransport);
>                duplexBridge.setBrokerService(broker.getBrokerService());
>                // now turn duplex off this side
>                info.setDuplexConnection(false);
>                duplexBridge.setCreatedByDuplex(true);
>                duplexBridge.duplexStart(this, brokerInfo, info);
>                LOG.info("Created Duplex Bridge back to " +
> info.getBrokerName());
> ...
>
> I could use the current list of TransportConnection managed by the "parent"
> TransportConnector (which can be retreived in the TransportConnection
> class), to verify that a connection with the same brokerInfo.getBrokerId()
> is not already launched and throw an exception (and try to send it back) if
> the connection is always active ? Is it Ok ?
>
> On the Transport Side, the new bridge won't be created while the
> InactivityMonitor doesn't destroy the old bridge.
>
>
> Eric-AWL
>
>
> Eric-AWL wrote:
>>
>> 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 [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.
>>>>
>>>
>>>
>>>
>>
>>
>
> --
> View this message in context: http://old.nabble.com/Duplex-and-network-fault.-tp29205793p29228003.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>