Hi, Jiaju Could you please reply to this message?
Regards, Yusuke. 2013/1/28 yusuke iida <yusk.i...@gmail.com>: > Hi, Jiaju > > 2013/1/15 Jiaju Zhang <jjzh...@suse.de>: >> On Tue, 2013-01-15 at 11:28 +0900, yusuke iida wrote: >>> Hi, Jiaju >>> >>> 2013/1/11 Jiaju Zhang <jjzh...@suse.de>: >>> > Hi Yusuke, >>> > >>> > Sorry for the late reply;) >>> > >>> > On Mon, 2013-01-07 at 13:50 +0900, yusuke iida wrote: >>> >> Hi, Jiaju >>> >> >>> >> When the proposal was conflict, I want to keep on the site of the >>> >> original lease. >>> >> I do not want to generate a revoke when maintained. >>> >> >>> >> >>> >> I made a patch according to a thought of "5.2 Master lease" described >>> >> in the next article. >>> >> It means that it prevents you from accepting new suggestion until a >>> >> time limit of lease expires. >>> > >>> > Exactly. >>> > >>> >> >>> >> http://www.read.seas.harvard.edu/~kohler/class/08w-dsi/chandra07paxos.pdf >>> >> >>> >> Is there anything wrong with this idea? >>> > >>> > This idea is totally right. But we have already implemented it. When the >>> > master exists and is still in its lease, if some other one wants to be >>> > the master and sent the "prepare" message, the acceptor will told him >>> > "oh, we have already had a master" by setting "hdr->leased = 1" in his >>> > respond message, actually this is a rejection, then the one trying to be >>> > master won't succeed. >>> I understand these specifications. >>> However, by the present specification, when returning "hdr->leased = >>> 1", "highest_promised" is updated by ballot of new "prepare". >>> When "highest_promised" is updated, reaccession of lease is carried >>> out in original masters. >>> Since revoke is performed at this time, the node which the resource >>> was start(ing) is STONITH(ed) by loss-policy=fence. >>> As for this, the stop of temporary service happens. >>> To avoid this, I've implemented the change not to do to re-acquire the >>> lease. >> >> Understood, this is an important fix. However, it seems that there is an >> easier way to fix this, just change the return value of "lease_promise", >> that is to say, return -1 when having leased. >> >> I'm inclined to do so because the new function "lease_is_leased" >> basically did the same thing with "lease_promise", but "lease_promise" >> returned a wrong value currently. What do you think?;) > I reconsidered this processing. > To be sure, "lease_is_leased" is redundant. > I moved a function of "lease_is_leased" to "lease_promise". > I'm not sure I should leave the "ability to get re-lease" existing. > With the patch which I made, a function is changed by the configuration file. > > The patch which I made again is here. > https://github.com/yuusuke/booth/commit/f99e74f38b51b89bf2deccb0eb2249a12fb45bb6 > >> >> BTW, don't forget to add your Signed-off-by line and check the patch >> with checkpatch.pl, this will make booth to use the same coding style;) > I understood it. > > BTW, we have noticed that some patents relevant to paxos exist, while > investigating about the technology of paxos. > Has the paxos algorithm used by booth cleared the problem about such a patent? > > Regards, > Yusuke >> >> Thanks, >> Jiaju >> >> >> > > -- > ---------------------------------------- > METRO SYSTEMS CO., LTD > > Yusuke Iida > Mail: yusk.i...@gmail.com > ---------------------------------------- -- ---------------------------------------- METRO SYSTEMS CO., LTD Yusuke Iida Mail: yusk.i...@gmail.com ---------------------------------------- _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org