Re: How to deregister Lateral Cache listeners in cluster?

Thank you for clarification Aaron.

Though I wished Lateral cache behaved a bit differently:
When LateralTCPSender fails to send a message to another node in cluster it
might try to reset the socket in case the failed node is back.  If it fails
again when remove the sender/listener pair for the failed node from its
list. When the failed node comes back the connections will be created again=
.
In this scenario LateralCacheMonitor, responsible for connection recovery i=
s
not needed.

Andrei.


Aaron Smuts wrote:
>=20
>=20
> The discovery system needs to deregister after a period of inactivity. =
=20
>=20
> The remote cache client queues items during the reconnect period.  It wil=
l
> send them once reconnected.  This isn't as easy to do in the lateral. =20
>=20
> Aaron
>=20
> --- On Mon, 7/6/09, Andrei Povodyrev <[email protected]> wrote:
>=20
>> From: Andrei Povodyrev <[email protected]>
>> Subject: How to deregister Lateral Cache listeners in cluster?
>> To: [email protected]
>> Date: Monday, July 6, 2009, 11:10 PM
>>=20
>>=20
>>=20
>> I am using Lateral Cache with Lateral Cache with UDP
>> discovery. When a node
>> in cluster goes down the other nodes do not discard their
>> senders
>> (LateralTCPSender) for the node. Is there way to remove
>> them?
>> Calling CompositeCacheManager.shutDown() on the node does
>> not help
>>=20
>> I am wondering why this behavior was programmed this way.
>> Would it be better
>> to recreate the senders/listeners when the node again joins
>> the cluster via
>> UDP discovery?
>>=20
>> The current implementation presents me with a risk of
>> losing cache events as
>> the object stream oos in LateralTCPSender is closed anyway
>> and first attempt
>> to send fails (EVEN when the node is back).
>> After failure is detected the sender is recreated by
>> LateralCacheMonitor
>> which
>> =C2=A0 *operates in a failure driven mode. That is,
>>  * it goes into a wait state until there is an error. Upon
>> the notification
>> of a
>>  * connection error, the monitor changes to operate in a
>> time driven mode.
>> That
>>  * is, it attempts to recover the connections on a periodic
>> basis. When all
>>  * failed connections are restored, it changes back to the
>> failure driven
>> mode
>>=20
>> All consecutive sends will be fine but the first one will
>> not get through. I
>> consider this to be a SEVERE case.
>>=20
>> Is there any trick I missed?
>>=20
>> Thank you very much for your help
>> --=20
>> View this message in context:
>> http://www.nabble.com/How-to-deregister-Lateral-Cache-listeners-in-clust=
er--tp24367699p24367699.html
>> Sent from the JCS - Dev mailing list archive at
>> Nabble.com.
>>=20
>>=20
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>=20
>>
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>=20
>=20
>=20

--=20
View this message in context: http://www.nabble.com/How-to-deregister-Later=
al-Cache-listeners-in-cluster--tp24367699p24577542.html
Sent from the JCS - Dev mailing list archive at Nabble.com.