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 13:40:21 GMT

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

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


Mime
View raw message