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 ---------------------------------------- _______________________________________________ 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
