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 [wor...@1ecc696e] WARN DemandForwardingBridge
>>>>
>>>> - Network connection between vm://SIBBusSupervisor-td0sib01s#12 and
>>>> tcp:///10.29.12.1:36485 shutdown due to a remote error:
>>>> org.apache.activemq.transport.InactivityIOException: Channel was
>>>> inactive
>>>> for too long: /10.29.12.1:36485
>>>> 2010-07-19 14:00:58,945 [0.29.12.1:36485] INFO DemandForwardingBridge
>>>>
>>>> - SIBBusSupervisor-td0sib01s bridge to
>>>> SIBBusModule-TestDeCharge-td0sib01v
>>>> stopped
>>>>
>>>>
>>>> It seems that bridge on Link 1 is finally broken ???
>>>>
>>>> Eric-AWL
>>>>
>>>>
>>>> Eric-AWL wrote:
>>>>>
>>>>> Hi
>>>>>
>>>>> In the case where network is alternatively on/off in a duplex
>>>>> multicast
>>>>> configuration, I first discovered that the "network connector side"
>>>>> broker was sometimes blocked on "RemoteBrokerNameKnownLatch" latch.
>>>>>
>>>>> I think that I resolved this problem by
>>>>> - adding a countdown() call on this latch at the end of the stop()
>>>>> method
>>>>> - correctly managing an exception to alert the discovery connector
>>>>> that
>>>>> the bridge was disposed during the start call.
>>>>>
>>>>> Now, I think that I have a problem on the other side with this
>>>>> configuration.
>>>>> T0 - A duplex connection is
>>>>> correctly
>>>>> established
>>>>> T0+X minutes - the network is down, the duplex
>>>>> bridge
>>>>> back is stopped, but the corresponding transport (back) connection
>>>>> seems
>>>>> not to be closed
>>>>> T0+X minutes + x ms - the networl is up : a new transport
>>>>> connection want to be established and is established
>>>>> T0+X minutes + y seconds - the transport inactivity thread closes
>>>>> the
>>>>> old transport connection
>>>>>
>>>>> (y seconds >> x milliseconds)
>>>>>
>>>>> All seems Ok, but no message are exchanged with this bridge.
>>>>>
>>>>> Eric-AWL
>>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://old.nabble.com/Duplex-and-network-fault.-tp29205793p29223448.html
>>> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>>>
>>
>>
>>
>
>
--
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.
