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 D3AE22C04B for ; Thu, 11 Apr 2019 08:43:43 -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 i0Xwt08D7qau for ; Thu, 11 Apr 2019 08:43:43 -0400 (EDT) Received: from smtp53.i.mail.ru (smtp53.i.mail.ru [94.100.177.113]) (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 1A4952C04A for ; Thu, 11 Apr 2019 08:43:43 -0400 (EDT) Received: by smtp53.i.mail.ru with esmtpa (envelope-from ) id 1hEZ3N-0005PO-Bq for tarantool-patches@freelists.org; Thu, 11 Apr 2019 15:43:41 +0300 Date: Thu, 11 Apr 2019 15:43:41 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH 1/1] swim: on address update increment incarnation Message-ID: <20190411124341.GA1331@chai> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: tarantool-patches@freelists.org * Vladislav Shpilevoy [19/04/10 22:22]: > In the original SWIM paper the incarnation is just a way of > refuting old statuses, nothing more. It is not designed as a > versioning system of a member and its non-status attributes. But > Tarantool harnesses the incarnation for wider range of tasks. > In Tarantool's implementation the incarnation (in theory) refutes > old statuses, old payloads, old addresses. > > But appeared, that before the patch an address update did not > touch incarnation. Because of that it was possible to rewrite a > new address with the old one back. The patch fixes it with a mere > increment of incarnation on each address update. > > The fix is simple because the current SWIM implementation > always carries the tuple {incarnation, status, address} together, > as a one big attribute. It is not so for payloads, so for them an > analogous fix will be much more tricky. I pushed this patch to master. -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov