ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Sapego <isap...@apache.org>
Subject Re: Best Effort Affinity for thin clients
Date Wed, 16 Jan 2019 11:53:17 GMT
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 <ptupitsyn@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 <isapego@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 <vozerov@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 <isapego@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 <
> vozerov@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 <
> > > > dsetrakyan@apache.org>
> > > > > wrote:
> > > > >
> > > > > > On Mon, Jun 18, 2018 at 11:07 AM, Denis Magda <dmagda@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.
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message