I think your response in this mail thread works for this use case: http://mail-archives.apache.org/mod_mbox/helix-user/201308.mbox/browser
Thanks, Venkat ________________________________ From: Krishnamoorthy, Venkata Sent: 2014, July, 29 4:34 PM To: [email protected] Subject: RE: Fencing Hi Kishore, Sorry abt the late response. The usecase is as follows: If multiple replicas of a partition has access to a common resource such as coherence cache or a databaseassuming that some kind of locking is required at the application level to do write update, if one of the replicas becomes offline from the point of Helix, then the particular replica needs to be forcibly restarted to avoid starvation for other replicas. I was wondering if this requirement can be achieved through Fencing concept using Helix. Thanks, Venkat ________________________________ From: kishore g [mailto:[email protected]] Sent: 2014, July, 24 3:24 PM To: [email protected] Subject: Re: Fencing Hi Venkat, We don't have explicit support for fencing. We provide some callbacks that can be used to deal with such scenarios. Can you give us more info on the scenario. What state model are you using, what is the shared resource and when you say unresponsive what could be the likely cause(e.g. GC). thanks, Kishore G On Thu, Jul 24, 2014 at 9:57 AM, Krishnamoorthy, Venkata <[email protected]<mailto:[email protected]>> wrote: Is there support for Fencing ( http://en.wikipedia.org/wiki/Fencing_(computing) ) in Helix? If not, how do I implement this feature to make sure that a participant that is not responsive is actually shutdown in order to avoid wrongful access to shared resources and race conditions? Please let me know. Thanks, Venkat ________________________________________ This E-Mail (including any attachments) may contain privileged or confidential information. It is intended only for the addressee(s) indicated above. The sender does not waive any of its rights, privileges or other protections respecting this information. Any distribution, copying or other use of this E-Mail or the information it contains, by other than an intended recipient, is not sanctioned and is prohibited. If you received this E-Mail in error, please delete it and advise the sender (by return E-Mail or otherwise) immediately. This E-Mail (including any attachments) has been scanned for viruses. It is believed to be free of any virus or other defect that might affect any computer system into which it is received and opened. However, it is the responsibility of the recipient to ensure that it is virus free. The sender accepts no responsibility for any loss or damage arising in any way from its use. E-Mail received by or sent from RBC Capital Markets is subject to review by Supervisory personnel. Such communications are retained and may be produced to regulatory authorities or others with legal rights to the information. IRS CIRCULAR 230 NOTICE: TO COMPLY WITH U.S. TREASURY REGULATIONS, WE ADVISE YOU THAT ANY U.S. FEDERAL TAX ADVICE INCLUDED IN THIS COMMUNICATION IS NOT INTENDED OR WRITTEN TO BE USED, AND CANNOT BE USED, TO AVOID ANY U.S. FEDERAL TAX PENALTIES OR TO PROMOTE, MARKET, OR RECOMMEND TO ANOTHER PARTY ANY TRANSACTION OR MATTER.
