Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (nike.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <29223448.post@talk.nabble.com>
Date: Wed, 21 Jul 2010 02:09:19 -0700 (PDT)
From: Eric-AWL <eric.vincent@atosorigin.com>
To: users@activemq.apache.org
Subject: Re: Duplex and network fault.
In-Reply-To: <29212515.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
References: <29205793.post@talk.nabble.com> <29212515.post@talk.nabble.com>


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     =
  =20
- 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 InactivityMonito=
r
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:
>=20
> 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=
    =20
> - Establishing network connection from
> vm://SIBBusModule-TestDeCharge-td0sib01v to
> tcp://td0sib01s.priv.atos.fr:61601?useLocalHost=3Dfalse
>=20
> 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   =
    =20
> - Network connection between vm://SIBBusModule-TestDeCharge-td0sib01v#4
> and
> tcp://td0sib01s.priv.atos.fr/10.21.195.130:61601(SIBBusSupervisor-td0sib0=
1s)
> has been established.
>=20
>=20
> STOP : Network Fault : Network Off
>=20
> Link 1 : ADMIN Link port 61601 : (DUPLEX initiator) Link from SIBBusModul=
e
> TestDeCharge(Client) to SIBBusSupervisor port 61601, broken
> 2010-07-19 14:00:23,258 [arge-td0sib01v]] INFO  DemandForwardingBridge   =
    =20
> - SIBBusModule-TestDeCharge-td0sib01v bridge to SIBBusSupervisor-td0sib01=
s
> stopped
>=20
> Reconnect Processus : Network On
>=20
> 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=
    =20
> - Establishing network connection from
> vm://SIBBusModule-TestDeCharge-td0sib01v to
> tcp://td0sib01s.priv.atos.fr:61601?useLocalHost=3Dfalse
>=20
> Link 1 new : ADMIN Link port 61601 : Connect (DUPLEX
> initiator)SIBBusModule TestDeCharge(Client) to SIBBusSupervisor port 6160=
1
> 2010-07-19 14:00:55,857 [ge-td0sib01v#11] INFO  DemandForwardingBridge   =
    =20
> - Network connection between vm://SIBBusModule-TestDeCharge-td0sib01v#11
> and
> tcp://td0sib01s.priv.atos.fr/10.21.195.130:61601(SIBBusSupervisor-td0sib0=
1s)
> has been established.
>=20
>=20
> Link 1 doesn=E2=80=99t seem to work.=20
>=20
> SIBBusSupervisor log
>=20
> 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      =
    =20
> - Created Duplex Bridge back to SIBBusModule-TestDeCharge-td0sib01v
> 2010-07-19 09:57:19,097 [or-td0sib01s#12] INFO  DemandForwardingBridge   =
    =20
> - Network connection between vm://SIBBusSupervisor-td0sib01s#12 and
> tcp:///10.29.12.1:36485(SIBBusModule-TestDeCharge-td0sib01v) has been
> established.
>=20
> STOP : Network Fault : Network Off
>=20
> 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   =
    =20
> - SIBBusSupervisor-td0sib01s bridge to SIBBusModule-TestDeCharge-td0sib01=
v
> stopped
>=20
>=20
> Reconnect Processus : Network On
>=20
> 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      =
    =20
> - Created Duplex Bridge back to SIBBusModule-TestDeCharge-td0sib01v
> 2010-07-19 14:00:55,921 [or-td0sib01s#22] INFO  DemandForwardingBridge   =
    =20
> - Network connection between vm://SIBBusSupervisor-td0sib01s#22 and
> tcp:///10.29.12.1:33840(SIBBusModule-TestDeCharge-td0sib01v) has been
> established.
>=20
> STOP Old DUPLEX back Connection
>=20
> 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   =
    =20
> - 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   =
    =20
> - SIBBusSupervisor-td0sib01s bridge to SIBBusModule-TestDeCharge-td0sib01=
v
> stopped
>=20
>=20
> It seems that bridge on Link 1 is finally broken ???
>=20
> Eric-AWL
>=20
>=20
> Eric-AWL wrote:
>>=20
>> Hi
>>=20
>> 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.
>>=20
>> I think that I resolved this problem by=20
>> - adding a countdown() call on this latch at the end of the stop() metho=
d
>> - correctly managing an exception to alert the discovery connector that
>> the bridge was disposed during the start call.
>>=20
>> 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
>>=20
>> (y seconds >> x milliseconds)
>>=20
>> All seems Ok, but no message are exchanged with this bridge.
>>=20
>> Eric-AWL
>>=20
>=20
>=20

--=20
View this message in context: http://old.nabble.com/Duplex-and-network-faul=
t.-tp29205793p29223448.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.