> to every server I did not think of this issue. Now I agree with your approach. Can you please add an explanation of this to the IEP?
Thanks! On Wed, Jan 16, 2019 at 2:53 PM Igor Sapego <isap...@apache.org> wrote: > Pavel, > > Yeah, it makes sense, but to me it seems that this approach can lead > to more complicated client logic, as it will require to make additional > call > to every server, that reports affinity topology change. > > Guys, WDYT? > > Best Regards, > Igor > > > On Tue, Jan 15, 2019 at 10:59 PM Pavel Tupitsyn <ptupit...@apache.org> > wrote: > > > 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 <isap...@apache.org> 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 <voze...@gridgain.com > > > > > 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 <isap...@apache.org> > > 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 < > > voze...@gridgain.com > > > > > > > > > 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 < > > > > > dsetrak...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > On Mon, Jun 18, 2018 at 11:07 AM, Denis Magda < > dma...@apache.org > > > > > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > >
