Igor, I have a feeling that we should omit Cache Group stuff from the protocol. It is a rare use case and even then dealing with them on client barely saves some memory.
We can keep it simple and have partition map per cacheId. Thoughts? On Fri, Feb 1, 2019 at 6:49 PM Igor Sapego <isap...@apache.org> wrote: > Guys, I've updated the proposal once again [1], so 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 Thu, Jan 17, 2019 at 1:05 PM Igor Sapego <isap...@apache.org> wrote: > > > Yeah, I'll add it. > > > > Best Regards, > > Igor > > > > > > On Wed, Jan 16, 2019 at 11:08 PM Pavel Tupitsyn <ptupit...@apache.org> > > wrote: > > > >> > 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. > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > > >
