From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Subject: Re: [tarantool-patches] Re: [PATCH v3 6/6] [RAW] swim: introduce payload References: <5dca8948367f2fd35e9bcd5eefcdf26254e7f49d.1546077015.git.v.shpilevoy@tarantool.org> <20190109135816.GG20509@chai> From: Vladislav Shpilevoy Message-ID: Date: Tue, 15 Jan 2019 17:42:06 +0300 MIME-Version: 1.0 In-Reply-To: <20190109135816.GG20509@chai> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit To: tarantool-patches@freelists.org, Konstantin Osipov Cc: vdavydov.dev@gmail.com List-ID: On 09/01/2019 16:58, Konstantin Osipov wrote: > * Vladislav Shpilevoy [18/12/29 15:07]: > > If the payload is the same for all members, why keep a copy in > each member? > It is not the same. Payload is a mere attribute of member, just like status, incarnation, ip, port. Each member can disseminate its own payload, and once it is changed, other members learn it via dissemination component and forward this event to other members. It allows 1) do not block other members payload change, when another member tries to change the global payload; 2) do not implement complex logic of payload changes merge, when multiple members are modifying the payload; 3) atomic and granulated update of payloads. When one member changes its payload, it is not necessary to disseminate payloads of all other known members; 4) each member can have a payload of size up to packet size, while in your proposal the global payload for *all* members will be limited by this limit. Your proposal is a global payload, but it turns the cluster into a giant bus line, where while one member occupies the line, other members can not neither put out their own arbitrary payload, nor send an answer on the active payload without its modification or removal.