jakarta-jcs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Povodyrev <povody...@nodalexchange.com>
Subject Re: How to deregister Lateral Cache listeners in cluster?
Date Mon, 20 Jul 2009 21:04:56 GMT

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 is
not needed.

Andrei.


Aaron Smuts wrote:
> 
> 
> The discovery system needs to deregister after a period of inactivity.  
> 
> The remote cache client queues items during the reconnect period.  It will
> send them once reconnected.  This isn't as easy to do in the lateral.  
> 
> Aaron
> 
> --- On Mon, 7/6/09, Andrei Povodyrev <povodyrev@nodalexchange.com> wrote:
> 
>> From: Andrei Povodyrev <povodyrev@nodalexchange.com>
>> Subject: How to deregister Lateral Cache listeners in cluster?
>> To: jcs-dev@jakarta.apache.org
>> Date: Monday, July 6, 2009, 11:10 PM
>> 
>> 
>> 
>> 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
>> 
>> 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?
>> 
>> 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
>>   *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
>> 
>> All consecutive sends will be fine but the first one will
>> not get through. I
>> consider this to be a SEVERE case.
>> 
>> Is there any trick I missed?
>> 
>> Thank you very much for your help
>> -- 
>> View this message in context:
>> http://www.nabble.com/How-to-deregister-Lateral-Cache-listeners-in-cluster--tp24367699p24367699.html
>> Sent from the JCS - Dev mailing list archive at
>> Nabble.com.
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
>> 
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jcs-dev-help@jakarta.apache.org
> 
> 
> 

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


---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-dev-help@jakarta.apache.org


Mime
View raw message