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 20:44:10 GMT
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.
> 


Mime
View raw message