I've committed the following change which should prevent this from happening again: http://hg.beekhof.net/lha/crm-stable/rev/e4a4f12e9c2d
On 12/27/06, home_king <[EMAIL PROTECTED]> wrote:
Hi, Andrew. It is hard to repeat the problem. Because the pitfall that I described only work under the edge conditions, such as DC has a high payload, or some crmd broadcasts NON-VOTE messages slowly. However, I indeed ever encountered that condtions. This pitfall is based on two facts: 1. VOTE may be launched in non-atomic manner 2. Once receiving a NON-VOTE from some node, no matter it's outdated or not, no matter the 'voted' hash is empty (because the lastest ELECTION is already over) that time or not, it will be recorded in the 'voted' hash. Of course, I also found there exists some casual remedy for the pitfall. 1. callback of CCM event will skip the obsolete items in 'voted' 2. g_hash_table_replace() will replace the old key with the new key (NO-VOTEDs which come from the same node), though their corresponding "current_election_id" are different. The exist documents is old, will you please provide (write) some fresh & detail documents (about the design & key implementation of crmd family) for the linux-ha-fans? After all, the code of crmd family (including cib,pe, te,ccm,lrm) take up the biggest part of the whole hb, I think. _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
_______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
