From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 2084731658 for ; Fri, 21 Jun 2019 15:02:57 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLbXfhJGh6S2 for ; Fri, 21 Jun 2019 15:02:57 -0400 (EDT) Received: from smtp57.i.mail.ru (smtp57.i.mail.ru [217.69.128.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 3760F3164A for ; Fri, 21 Jun 2019 15:02:55 -0400 (EDT) Subject: [tarantool-patches] Re: [PATCH 2/2] swim: introduce generation References: <9852675764d25bdc720023ed6763d97cbeab8bee.1561065646.git.v.shpilevoy@tarantool.org> <20190621065358.GF18958@atlas> From: Vladislav Shpilevoy Message-ID: <9a45ac3e-0bf7-6aad-e673-494c1e20a8da@tarantool.org> Date: Fri, 21 Jun 2019 21:03:31 +0200 MIME-Version: 1.0 In-Reply-To: <20190621065358.GF18958@atlas> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: Konstantin Osipov Cc: tarantool-patches@freelists.org On 21/06/2019 08:53, Konstantin Osipov wrote: > * Vladislav Shpilevoy [19/06/21 00:25]: > > Generation and incarnation look and sound similar, so it is hard > to tell which is which. > > I'd like to suggest renaming 'generation' to 'epoch'. > > "Age" would be a wrong name for a pair "epoch" + "incarnation". > > Besides, swim's term for the counter is "incarnation", so I would > stick to the swim terminology. > > I suggest this: > > struct swim_incarnation { > int64_t term; // Derived from RAFT word "term", persisted between restarts > int64_t version; // Reflects swim member state version > }; > > I am open to alternatives too. > Basically, you do not like that I kept generation out of incarnation. I did it deliberately to emphasize that SWIM's incarnation is not the same as our 'age'. Additionally, it allows not to change API and keep incarnation as a simple number. If we say, that incarnation is a structure, then I am not sure how to return it in public API. Split all methods operating on incarnation in 2 parts? Assume, that we decided to split, and can encapsulate everything inside the incarnation. 'version' for volatile part sounds good. 'term' does not. Raft uses 'term' as a version of round, not a version of an instance. It is about cluster state, not an instance state. 'epoch' is the same IMO. Furthermore, both 'epoch' and 'term' are dynamic usually. 'Generation' was perfect - it means 'поколение'. And it is logically to increment it only when an instance dies and starts again, and never change during lifetime. If you still think, that the complex incarnation is the best, I suggest incarnation = { generation, version } It leads to the following changes in the API. - member:incarnation() + member:generation() + member:version() Method event:is_new_incarnation() will return true if generation or version are changed. To check which one a user will use event:is_new_version() event:is_new_generation() But I think, that current 'age' solution is better. It allows to do not touch core SWIM concept 'incarnation'. I am waiting for your decision on what to do.