From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> To: tarantool-patches@freelists.org Cc: kostja@tarantool.org Subject: [tarantool-patches] Re: [PATCH 5/5] swim: introduce dissemination component Date: Mon, 8 Apr 2019 23:13:13 +0300 [thread overview] Message-ID: <d5081fa8-8d2d-b012-afb9-7890b4f8435c@tarantool.org> (raw) In-Reply-To: <2b1e97522dfeb839b429f56543b51e8e61e76cbd.1554465150.git.v.shpilevoy@tarantool.org> Kostja pushed some comment updates. I copy-pasted them below and fixed or reverted some of them with an explanation why. Please, do not forget to answer on this email and others in the thread with an LGTM or new review fixes/comments. > commit ce5b71857310b7c692d6d5eb8aae3f2bc2604320 > Author: Konstantin Osipov <kostja@tarantool.org> > Date: Mon Apr 8 17:25:13 2019 +0300 > > swim: update comments, use singular in method names. > > diff --git a/src/lib/swim/swim.c b/src/lib/swim/swim.c > index 8eac102c8..215960911 100644 > --- a/src/lib/swim/swim.c > +++ b/src/lib/swim/swim.c > @@ -274,22 +274,47 @@ struct swim_member { > * Dissemination component > * > * Dissemination component sends events. Event is a > - * notification about member status update. So formally, > - * this structure already has all the needed attributes. > - * But also an event somehow should be sent to all members > - * at least once according to SWIM, so it requires > - * something like TTL for each type of event, which gets > - * decremented on each send. And a member can not be > - * removed from the global table until it gets dead and > - * its status TTLs is 0, so as to allow other members > - * learn its dead status. > + * notification about some member state update. We maintain > + * a different event type for each significant member > + * attribute - status, incarnation, etc to not send entire > + * member state each time any member attribute changes. > + * The state of an event is stored within My update: ================================================================== * Dissemination component sends events. Event is a - * notification about some member state update. We maintain - * a different event type for each significant member - * attribute - status, incarnation, etc to not send entire + * notification about some member state update. The member + * maintains a different event type for each significant + * attribute - status, incarnation, etc not to send entire * member state each time any member attribute changes. - * The state of an event is stored within ================================================================== 1) Note, that I deliberately avoid personalization in the comments. IMO, too extensive usage of 'we', 'us' and other pronouns harms readability. Sometimes it is not obvious what do you mean by 'we'/'us', and it is better to say explicitly 'instance', 'member' etc. After all, it is not a chat or face-to-face conversation. It is a document. 2) In English 'to not do ...' is wrong, it is rather Russian construction. In English they use 'not to do ...'. 3) I dropped 'stored within' because obviously that sentence is truncated, and makes no sense. > + * > + * According to SWIM, an event should be sent to > + * all members at least once. It'd be silly to continue > + * sending an old event if a member attribute has changed > + * since the beginning of the round. To this end > + * we also maintain TTL (time-to-live) counter > + * associated with each event type. My update: ================================================================== - * According to SWIM, an event should be sent to - * all members at least once. It'd be silly to continue - * sending an old event if a member attribute has changed - * since the beginning of the round. To this end - * we also maintain TTL (time-to-live) counter - * associated with each event type. + * According to SWIM, an event should be sent to all + * members at least once - for that a TTL (time-to-live) + * counter is maintained for each independent event type. ================================================================== I dropped "It'd be silly ..." because I do not see a link to that sentence. Sending old outdated member attribute value and sending an attribute only once has nothing to do in common. > + * > + * When a member state changes, the TTL is reset to the > + * cluster size. It is then decremented after each send. > + * This guarantees that each member state change is sent > + * to each SWIM member at least once. If a new event of > + * the same type is generated before a round is finished, > + * we update the current event object and reset the > + * relevant TTL. My update: ================================================================== - * we update the current event object and reset the - * relevant TTL. + * the current event object is updated in place with reset + * of the TTL. ================================================================== I dropped 'we'. > + * > + * To conclude, TTL works in two ways: to see which > + * specific member attribute needs dissemination and to > + * track how many cluster members still need to learn > + * about the change from us. My update: ================================================================== - * about the change from us. + * about the change from this instance. ================================================================== I dropped 'us'. > + */ > + > + /** > + * status_ttl is reset whenever a member status changes. > + * We also reset it whenever any other attribute changes, > + * to be able to easily track whether we need to send > + * any events at all. > + * Besides, a dead member can not be removed from the > + * member table until its status TTL is 0, so as to allow > + * other members learn its dead status. My update: ================================================================== /** - * status_ttl is reset whenever a member status changes. - * We also reset it whenever any other attribute changes, - * to be able to easily track whether we need to send - * any events at all. - * Besides, a dead member can not be removed from the - * member table until its status TTL is 0, so as to allow - * other members learn its dead status. + * General TTL reset each time when any visible member + * attribute is updated. It is always bigger or equal than + * any other TTLs. In addition it helps to keep a dead + * member not dropped until the TTL gets zero so as to + * allow other members to learn the dead status. ================================================================== I dropped 'status_ttl' name from all the comments, because it is an erroneous practice to duplicate compilable code into comments. If in future status_ttl name is changed, we 100% will not update some of the comments and will have the same that we deal in SQLite code with. Also, I dropped 'we'. > */ > int status_ttl; > /** > - * Events are put into a queue sorted by event occurrence > - * time. > + * All created events are put into a queue sorted by event time. > */ > - struct rlist in_events_queue; > + struct rlist in_event_queue; > }; > @@ -708,7 +739,7 @@ swim_new_round(struct swim *swim) > /** > * Encode anti-entropy header and random members data as many as > * possible to the end of the packet. > - * @retval Number of key-values added to the packet's root map. > + * @retval Number of key-value pairs added to the packet's root map. I've reverted that change, because - it has nothing in common with the patch. It is an old anti-entropy comment, not a new dissemination code. - we have exactly the same @retval comment on other swim_encode_...() functions. I think, that they should be consistent. - it pollutes git history. > */ > static int > swim_encode_anti_entropy(struct swim *swim, struct swim_packet *packet)
next prev parent reply other threads:[~2019-04-08 20:13 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-05 11:57 [tarantool-patches] [PATCH 0/5] swim " Vladislav Shpilevoy 2019-04-05 11:57 ` [tarantool-patches] [PATCH 1/5] swim: encapsulate member bin info into a 'passport' Vladislav Shpilevoy 2019-04-05 11:57 ` [tarantool-patches] [PATCH 2/5] swim: make members array decoder be a separate function Vladislav Shpilevoy 2019-04-05 11:57 ` [tarantool-patches] [PATCH 3/5] test: speed up swim big cluster failure detection Vladislav Shpilevoy 2019-04-09 8:43 ` [tarantool-patches] " Konstantin Osipov 2019-04-09 11:47 ` Vladislav Shpilevoy 2019-04-05 11:57 ` [tarantool-patches] [PATCH 4/5] test: set packet drop rate instead of flag in swim tests Vladislav Shpilevoy 2019-04-05 11:57 ` [tarantool-patches] [PATCH 5/5] swim: introduce dissemination component Vladislav Shpilevoy 2019-04-08 20:13 ` Vladislav Shpilevoy [this message] 2019-04-09 9:58 ` [tarantool-patches] " Konstantin Osipov 2019-04-09 11:47 ` Vladislav Shpilevoy 2019-04-09 12:25 ` [tarantool-patches] Re: [PATCH 0/5] swim " Vladislav Shpilevoy
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=d5081fa8-8d2d-b012-afb9-7890b4f8435c@tarantool.org \ --to=v.shpilevoy@tarantool.org \ --cc=kostja@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='[tarantool-patches] Re: [PATCH 5/5] swim: introduce dissemination component' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox