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 <povody...@nodalexchange.com> wrote: > From: Andrei Povodyrev <povody...@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-unsubscr...@jakarta.apache.org > For additional commands, e-mail: jcs-dev-h...@jakarta.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: jcs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: jcs-dev-h...@jakarta.apache.org