From dev-return-44056-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Tue Jan 15 21:00:01 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 76A8E180609 for ; Tue, 15 Jan 2019 21:00:00 +0100 (CET) Received: (qmail 47374 invoked by uid 500); 15 Jan 2019 19:59:59 -0000 Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list dev@ignite.apache.org Received: (qmail 47363 invoked by uid 99); 15 Jan 2019 19:59:59 -0000 Received: from mail-relay.apache.org (HELO mailrelay1-lw-us.apache.org) (207.244.88.152) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Jan 2019 19:59:59 +0000 Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 7149443F7 for ; Tue, 15 Jan 2019 19:59:58 +0000 (UTC) Received: by mail-lj1-f178.google.com with SMTP id q2-v6so3410151lji.10 for ; Tue, 15 Jan 2019 11:59:58 -0800 (PST) X-Gm-Message-State: AJcUukcDzvnisNCIAULdZq2SZSKNgmoeuz5RSDXPAYdikqYUBqcySky4 Nwv03CcVY/xGC82XXZxK+RV3uyQHz0t88KTgQQ== X-Google-Smtp-Source: ALg8bN4NAr3UeXGOJo9HI3/D9EJi+YPc14K6ONve3gQDrW9bFqNug9JaRRcpSAorAiMW02LTVybtsK7S3f25rR1ZvOw= X-Received: by 2002:a2e:890b:: with SMTP id d11-v6mr3839210lji.113.1547582397215; Tue, 15 Jan 2019 11:59:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Pavel Tupitsyn Date: Tue, 15 Jan 2019 22:59:45 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Best Effort Affinity for thin clients To: dev Content-Type: multipart/alternative; boundary="0000000000000bf933057f849b70" --0000000000000bf933057f849b70 Content-Type: text/plain; charset="UTF-8" Igor, > It is proposed to add flag to every response, that shows whether the Affinity Topology Version of the cluster has changed since the last request from the client. I propose to keep this flag. So no need for periodic checks. Makes sense? On Tue, Jan 15, 2019 at 4:45 PM Igor Sapego wrote: > Pavel, > > This will require from client to send this new request periodically, I'm > not > sure this will make clients simpler. Anyway, let's discuss it. > > Vladimir, > > With current proposal, we will have affinity info in message header. > > Best Regards, > Igor > > > On Tue, Jan 15, 2019 at 11:01 AM Vladimir Ozerov > wrote: > > > Igor, > > > > I think that "Cache Partitions Request" should contain affinity topology > > version. Otherwise we do not know what distribution is returned - the one > > we expected, or some newer one. The latter may happen in case topology > > changed or late affinity assignment happened between server response and > > subsequent client partitions request. > > > > Vladimir. > > > > On Mon, Jan 14, 2019 at 6:08 PM Igor Sapego wrote: > > > > > Hello guys, > > > > > > I've updated IEP page [1] describing proposed solution in more details > > and > > > proposing some changes for a protocol. > > > > > > Please, take a look and let me know what you think. > > > > > > [1] - > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients > > > > > > Best Regards, > > > Igor > > > > > > > > > On Tue, Jun 19, 2018 at 11:54 AM Vladimir Ozerov > > > > wrote: > > > > > > > Denis, > > > > > > > > Yes, in principle we can extend it. We are going to implement it in > > > > subsequent phases of this IEP. > > > > > > > > On Tue, Jun 19, 2018 at 4:30 AM, Dmitriy Setrakyan < > > > dsetrakyan@apache.org> > > > > wrote: > > > > > > > > > On Mon, Jun 18, 2018 at 11:07 AM, Denis Magda > > > wrote: > > > > > > > > > > > Folks, > > > > > > > > > > > > Feel that this functionality can be extended to the automatic > > > > reconnect, > > > > > > can't it? Presently we require to provide a static list of IPs to > > be > > > > used > > > > > > at a reconnect time. By having a partition map of all the nodes, > > the > > > > thin > > > > > > client should be able to automate this piece. > > > > > > > > > > > > > > > > Not sure if static IP list can be avoided. What Igor is suggesting > is > > > > that > > > > > we try to pick the best node out of the static IP list. > > > > > > > > > > D. > > > > > > > > > > > > > > > --0000000000000bf933057f849b70--