Hi Igor, Looks good to me in general, except changing the response message format so much.
Can we use a separate message to retrieve affinity topology version? Set a flag as you describe, but don't put the version data into standard response? Just to keep the protocol cleaner, follow SRP to some extent, and keep client implementations simpler (especially for clients that ignore this flag). Thoughts? 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. > > > > > >
