You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jcs-users@jakarta.apache.org by Andrei Povodyrev <po...@nodalexchange.com> on 2009/07/02 00:50:22 UTC
How to deregister Lateral Cache listeners in cluster
Hi there
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-tp24298365p24298365.html
Sent from the JCS - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org
Re: How to deregister Lateral Cache listeners in cluster
Posted by Aaron Smuts <as...@yahoo.com>.
I'm looking for a way to cleanly mark a lateral sender as bad and in need of verification. But for now, the lateral will use the queuing zombie, just like the remote cache. The failure will be queued and then propagated on reconnect. I added this feature in 1.3.3.3-RC.
Aaron
--- On Wed, 7/1/09, Andrei Povodyrev <po...@nodalexchange.com> wrote:
> From: Andrei Povodyrev <po...@nodalexchange.com>
> Subject: How to deregister Lateral Cache listeners in cluster
> To: jcs-users@jakarta.apache.org
> Date: Wednesday, July 1, 2009, 3:50 PM
>
> Hi there
>
> 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-tp24298365p24298365.html
> Sent from the JCS - Users mailing list archive at
> Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jcs-users-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org