activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric-AWL <eric.vinc...@atosorigin.com>
Subject Re: Duplex and network fault.
Date Thu, 22 Jul 2010 06:50:05 GMT

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

-- 
View this message in context: http://old.nabble.com/Duplex-and-network-fault.-tp29205793p29233761.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Mime
View raw message